-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
I agree that variable record length is needed in some use cases, but there are better ways for lower latency than reducing record size. |
Adding a footer to support incomplete record streaming might be better suited for discussion in #25 and is independent of a variable record length. |
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. |
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):
|
(does "no" to one mean no variable length headers [except for the ID voted elsewhere], or headers only of length 2^X?) |
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 |
|
As @crotwell says - this issue is about the length of complete records. |
(but: has anybody practically checked the additional overhead of e.g. finding a specific time interval in a dayfile?) |
|
Yes (no restriction)
Uint32 |
|
|
|
Support variable length records for efficiency and flexibility (e.g. real time streaming with lower latency).
The text was updated successfully, but these errors were encountered: