Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requirement: Support variable length records for efficiency and flexibility #15

Open
krischer opened this issue Jan 3, 2018 · 14 comments

Comments

@krischer
Copy link
Contributor

krischer commented Jan 3, 2018

Support variable length records for efficiency and flexibility (e.g. real time streaming with lower latency).

@andres-h
Copy link

andres-h commented Jan 6, 2018

I agree that variable record length is needed in some use cases, but there are better ways for lower latency than reducing record size.

@krischer
Copy link
Contributor Author

krischer commented Jan 8, 2018

Adding a footer to support incomplete record streaming might be better suited for discussion in #25 and is independent of a variable record length.

@crotwell
Copy link

crotwell commented Jan 8, 2018

I think there is a need for variable length on the larger end as well, useful for saving processed data in fewer large chunks instead of breaking in to many small records. The current miniseed power of 2 system is too coarse.

The size of the variable record and the maximum number of samples header need to be compatible. Previous discussions were for a Uint16, so 64K max for both.

@krischer
Copy link
Contributor Author

Summary

(Please let me know if I missed a point or misunderstood something)

Please vote on (compatibility of the number of samples field is implied):

  1. Do we want variable length headers without being restricted to a length of 2^X?
  2. What should the maximum length be? Likely determined by the data type used to store the maximum length. (Uint16=65536 bytes / Uint32=4294967296 bytes / other suggestion).

@kaestli
Copy link

kaestli commented Jan 29, 2018

(does "no" to one mean no variable length headers [except for the ID voted elsewhere], or headers only of length 2^X?)

@crotwell
Copy link

I think this is "variable length records", not headers? So existing is like 512 or 4096 and BGF records could be 593 or 64201 bytes depending on need.

1 yes
2 Uint32 - with the caveat that datacenters may choose to limit input/output record sizes based on their needs.

@chad-earthscope
Copy link
Member

  1. Yes, variable length records.
  2. UINT16.

@krischer
Copy link
Contributor Author

(does "no" to one mean no variable length headers [except for the ID voted elsewhere], or headers only of length 2^X?)

As @crotwell says - this issue is about the length of complete records.

@kaestli
Copy link

kaestli commented Jan 30, 2018

  1. yes
  2. UINT32

(but: has anybody practically checked the additional overhead of e.g. finding a specific time interval in a dayfile?)

@ozym
Copy link

ozym commented Jan 30, 2018

  1. Yes
  2. Uint16

@claudiodsf
Copy link

  1. Do we want variable length headers without being restricted to a length of 2^X?

Yes (no restriction)

  1. What should the maximum length be? Likely determined by the data type used to store the maximum length. (Uint16=65536 bytes / Uint32=4294967296 bytes / other suggestion).

Uint32

@ihenson-bsl
Copy link

  1. yes
  2. Uint16

@ValleeMartin
Copy link

  1. Yes
  2. Uint32

@JoseAntonioJara
Copy link

  1. Yes, variable length records
  2. Uint32

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants