So I’m starting to hammer out some code for channel allocation on the
host side,
and this isn’t crucial because it’s going to be a #define which I can
easily
change… but what’s the max capacity per channel we’re looking at? I
don’t
recall seeing a concrete number somewhere. Same capacity on the control
channel?
On Mon, Apr 09, 2007 at 03:27:57AM -0400, George N. wrote:
So I’m starting to hammer out some code for channel allocation on the host
side, and this isn’t crucial because it’s going to be a #define which I can
easily change… but what’s the max capacity per channel we’re looking at?
I don’t recall seeing a concrete number somewhere. Same capacity on the
control channel?
- George
George, it’s not a max capacity per channel, it’s a maximum aggregate
capacity across all data channels (input and output). Use 32MB/s as
the maximum capacity. Ignore the control channel contribution.
USB is half-duplex, that’s why it’s the aggregate across the input +
output channels.
Eric
Eric B. wrote:
George, it’s not a max capacity per channel, it’s a maximum aggregate
capacity across all data channels (input and output). Use 32MB/s as
the maximum capacity. Ignore the control channel contribution.USB is half-duplex, that’s why it’s the aggregate across the input +
output channels.
Got ya. And each channel is associated with a single reservation. In
other words, if
there were 30 requests of .5MB each, even though there is spare capacity
it can no longer
be allocated until a channel is deallocated first? This is not to say
the capacity won’t
be used, but there are no more channels to allocate.
On Mon, Apr 09, 2007 at 03:14:12PM -0400, George N. wrote:
Got ya. And each channel is associated with a single reservation. In
other words, if there were 30 requests of .5MB each, even though there is
spare capacity it can no longer be allocated until a channel is deallocated
first? This is not to say the capacity won’t be used, but there are no
more channels to allocate.
Uhh, 30 requests of .5 is only 15MB/s, so there would be no problem
with additional requests up to an additional 17MB/s. The tx and rx
channels are allocated indepently of each other, though all capacity
requests are changed against the same pool.
Eric
Eric B. wrote:
Uhh, 30 requests of .5 is only 15MB/s, so there would be no problem
with additional requests up to an additional 17MB/s. The tx and rx
channels are allocated indepently of each other, though all capacity
requests are changed against the same pool.
Right, it was part of the example.
Based on your response… I think we have a problem with our interface.
cmd_allocate_channel(invocation_handle, channel, capacity_reservation)
cmd_deallocate_channel(invocation_handle, channel)
Regardless of whether we return a channel to the user, or the user
specifies a desired
channel…
How does cmd_deallocate_channel() know how much to de-allocate? If
these are hardware
channels we are talking about (currently 2 in hardware), and I now want
to deallocate my
channel and i say cmd_deallocate_channel(blah, 1) … I am going to
deallocate all of
channel 1 which is incorrect. The capacity I reserved should be
deallocated.
So then is it required for the requester to keep track of how much they
requested to pass
to our deallocation method?
On Mon, Apr 09, 2007 at 04:24:23PM -0400, George N. wrote:
Eric B. wrote:
Uhh, 30 requests of .5 is only 15MB/s, so there would be no problem
with additional requests up to an additional 17MB/s. The tx and rx
channels are allocated indepently of each other, though all capacity
requests are changed against the same pool.Right, it was part of the example.
Based on your response… I think we have a problem with our interface.
Take a look at usrp/host/lib/inband/usrp_server.mbh.
That’s the real interface. FYI, I’ve put a note in
inband-signaling-usb-host pointing to that file.
;; ----------------------------------------------------------------
;; usrp-channel
;;
;; The protocol class is defined from the client’s point-of-view.
;; (The client port is unconjugated, the server port is conjugated.)
(define-protocol-class usrp-channel
(:outgoing
(cmd-allocate-channel invocation-handle capacity-reservation)
;; The cmd-allocate-channel message requests that the server
;; allocates a logical channel in the FPGA for use.
;; capacity-reservation specifies the number of bytes/s of
;; interconnect capacity (USB or ethernet) to reserve for this
;; channel. (The reservation is just a sanity check, no OS
;; specific mechanism is used.)
(cmd-deallocate-channel invocation-handle channel)
;; The integer channel specifies the channel to deallocate.
)
(:incoming
(response-allocate-channel invocation-handle status channel)
;; If successful, a channel the specified capacity was allocated.
;; channel, an integer, indicates which channel was allocated.
(response-deallocate-channel invocation-handle status)
;; If successful, the specified channel and associated interconnect
;; capacity were deallocated.
)
)
Regardless of whether we return a channel to the user, or the user
specifies a desired channel…How does cmd_deallocate_channel() know how much to de-allocate?
It deallocates the amount that was originally allocated. What’s the
problem?
If these are hardware channels we are talking about (currently 2 in hardware), and I
now want to deallocate my channel and i say cmd_deallocate_channel(blah, 1)
… I am going to deallocate all of channel 1 which is incorrect. The
capacity I reserved should be deallocated.
I think there’s some confusion here. When a user requests an rx or tx
channel with (cmd-allocate-channel invocation-handle
capacity-reservation), they are given a channel on an exclusive basis.
The returned channel number is given in the response-allocate-channel
message.
When they send (cmd-deallocate-channel invocation-handle channel) the
server (after checking that this port actually does own channel)
frees the channel and gives the associated capacity reservation back to
the pool.
So then is it required for the requester to keep track of how much they
requested to pass to our deallocation method?
No, the server keeps track of how much it assigned to each rx and tx
channel.
Does this make sense?
Eric
George N. wrote:
- If a channel allocates capacity on a channel, …
if a port allocates capacity on a chanel, …
sorry
Eric B. wrote:
So then is it required for the requester to keep track of how much they
requested to pass to our deallocation method?No, the server keeps track of how much it assigned to each rx and tx
channel.Does this make sense?
OK this is starting to make more sense now. I just want to make sure I
have this 100%.
Heres a list of statements, tell me if any are false.
Once a port owns a channel, no other ports can allocate capacity on
it.
If a channel allocates capacity on a channel, it can make another
capacity reservation
request which can add additional capacity on to its allocated channel
through a second
cmd-allocate-channel request.
When a deallocation method is called, the channel is specified and all
of the capacity
reserved on the channel is free and the channel is no longer exclusive.
Why not just check which channel the port owns and deallocate it when
receiving a
cmd-deallocate-channel, rather than needing to pass the channel
parameter?
On Mon, Apr 09, 2007 at 05:42:30PM -0400, George N. wrote:
server (after checking that this port actually does own channel)
OK this is starting to make more sense now. I just want to make sure I
have this 100%.Heres a list of statements, tell me if any are false.
- Once a port owns a channel, no other ports can allocate capacity on it.
Yes.
- If a channel allocates capacity on a channel, it can make another
capacity reservation request which can add additional capacity on to its
allocated channel through a second cmd-allocate-channel request.
To keep life simple, I’d say no. If this turns out to be an issue, we
could add an
(adjust-capacity-reservation invocation-handle channel delta-capacity)
request.
- When a deallocation method is called, the channel is specified and all of
the capacity reserved on the channel is free
Yes.
and the channel is no longer exclusive.
It’s no longer assigned to this port, and is available for reassignment
Why not just check which channel the port owns and deallocate it when
receiving a cmd-deallocate-channel, rather than needing to pass the channel
parameter?
There’s nothing stopping a given port from allocating more than one
channel 
Eric
Thanks for the help Eric 
I checked in to my branch a first pass on allocating and deallocating
the channels from
the specifications in usrp_server.mbh. Seems pretty straight forward.
Feedback of course!
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs