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.

Sign up for GitHub

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

Jump to bottom

[libbladeRF] bladerf_sync_tx() is limited by # xfers, not # buffers #438

Closed
jynik opened this issue Nov 19, 2015 · 3 comments
Closed

[libbladeRF] bladerf_sync_tx() is limited by # xfers, not # buffers #438

jynik opened this issue Nov 19, 2015 · 3 comments
Assignees
@jynik
Labels
Issue: Bug It's a bug and it oughta be fixed

Comments

@jynik
Copy link
Contributor

jynik commented Nov 19, 2015

While making successive bladerf_sync_tx() calls with N seconds worth of samples, I was finding that the bladerf_sync_tx() call was taking longer than N seconds to execute, despite having given bladerf_sync_config() excess of N seconds worth of buffers.

Upon digging further, this is due to design flaw in the bladerf_sync_tx() implementation. Buffer are submitted to the async subsystem in the caller's context, and this blocks if no USB transfers are available. The sync worker's callback does not return any buffers for submission, and instead relies on submissions from the callers context. Therefore, the # transfers is the limiting factor.

What we instead want is the caller's context to be able to insert samples into the buffer and return, and have the callback function submitting pending samples. An important caveat here is that the worker callback cannot block.
@jynik jynik added the Issue: Bug It's a bug and it oughta be fixed label Nov 19, 2015
@jynik jynik self-assigned this Nov 19, 2015
@jynik
Copy link
Contributor Author

jynik commented Nov 19, 2015

To address this, we shall introduce the concept of who is responsible for submitting buffers to the async system: the bladerf_sync_tx() context or the worker callback context.

Buffer management data is accessed atomically, so this data is where we can maintain this notion of the "current submitter."

jynik pushed a commit that referenced this issue Nov 20, 2015
libbladeRF: Added "non-block" option to internal async buffer submission
2851eb0 
This is one step towards addressing issue #438; we must first
know that we are unable to submit a buffer so that we can defer
its submission to a later callback.
jynik pushed a commit that referenced this issue Nov 20, 2015
libbladeRF: Added "non-block" option to internal async buffer submission
3a0179d 
This is one step towards addressing issue #438; we must first
know that we are unable to submit a buffer so that we can defer
its submission to a later callback.
jynik pushed a commit that referenced this issue Nov 20, 2015
libbladeRF: Utilize all available TX buffers
4d51274 
This fixes issue #438, in which the bladerf_sync_tx() implementation
was limited by the number of transfers, and not taking advantage
of the available TX buffers (beyond N=<num_transfers>).

This is addressed by allowing the bladerf_sync_tx() context to defer
buffer submission to the sync TX callback handler when it is unable to
submit filled buffers.

Once assigned the responsibility of submitting deferred (filled)
buffers, the sync TX callback will continue to do so until
no filled buffers are available. At this point, the callback
relinquishes its submission duty back to the bladerf_sync_tx() context.
jynik pushed a commit that referenced this issue Nov 20, 2015
libbladeRF: Added bladerf_submit_stream_buffer_nb()
5d59303 
This provides a non-blocking variant of bladerf_submit_stream_buffer(),
which provides API users with more control over how they might want
to handle asynchronous buffer submission.

This API functionality has been exposed to allow users to implement
schemes similar to that used to address Issue #438.
@jynik
Copy link
Contributor Author

jynik commented Nov 20, 2015

Pending fix is up in a dev-issue_438 branch.

jynik pushed a commit that referenced this issue Nov 20, 2015
@jynik
libbladeRF: Added "non-block" option to internal async buffer submission
3dafac7 
This is one step towards addressing issue #438; we must first
know that we are unable to submit a buffer so that we can defer
its submission to a later callback.
jynik pushed a commit that referenced this issue Nov 20, 2015
@jynik
libbladeRF: Utilize all available TX buffers
6b19788 
This fixes issue #438, in which the bladerf_sync_tx() implementation
was limited by the number of transfers, and not taking advantage
of the available TX buffers (beyond N=<num_transfers>).

This is addressed by allowing the bladerf_sync_tx() context to defer
buffer submission to the sync TX callback handler when it is unable to
submit filled buffers.

Once assigned the responsibility of submitting deferred (filled)
buffers, the sync TX callback will continue to do so until
no filled buffers are available. At this point, the callback
relinquishes its submission duty back to the bladerf_sync_tx() context.
jynik pushed a commit that referenced this issue Nov 20, 2015
@jynik
libbladeRF: Added bladerf_submit_stream_buffer_nb()
f0f3783 
This provides a non-blocking variant of bladerf_submit_stream_buffer(),
which provides API users with more control over how they might want
to handle asynchronous buffer submission.

This API functionality has been exposed to allow users to implement
schemes similar to that used to address Issue #438.
@jynik
Copy link
Contributor Author

jynik commented Nov 20, 2015

Addressed in 6b19788.

@jynik jynik closed this as completed Nov 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jynik jynik

Labels
Issue: Bug It's a bug and it oughta be fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jynik