On Wed, Apr 7, 2010 at 4:54 PM, Per Zetterberg wrote:
> Dear All,
>
> Regarding MAC layer development I would like to empasize on the importance
> of time-stamps. With time-stamps we can at least do slotted schemes. Maybe
> non-slotted schemes can be approximated by slotted ones ?
>
Hi Per,
I'm
Dear All,
Regarding MAC layer development I would like to empasize on the
importance of time-stamps. With time-stamps we can at least do slotted
schemes. Maybe non-slotted schemes can be approximated by slotted ones ?
BR/
Per
___
Discuss-gnuradio
John-
>> Which part of the Linux issue... sustained throughput or latency? I
>> wouldn't be surprised to find that latency
>> hasn't
>> improved substantially because it's not a priority for server software.
>> Even VoIP applications are not concerned
>> about a 1 msec improvement... whereas t
Marcus-
> On 04/06/2010 09:44 PM, John Gilmore wrote:
>>> Which part of the Linux issue... sustained throughput or latency? I
>>> wouldn't be surprised to find that latency
>>> hasn't
>>> improved substantially because it's not a priority for server software.
>>> Even VoIP applications are not
George-
>> What I got from your paper is that the matched filter approach for
>> fast packet detection would not work in an OFDM setting. What about
>> fast ACK generation? Would it require an IFFT implementation on the
>> USRP? Would it help much?
>
> It's a good question, and something I haven't
George-
>> Did you see my previous post about the accelerator PCIe card? To some
>> extent the Microsoft approach is what we're
>> doing. But we want to stay compatible with USRP2 hardware so we connect
>> GbE to the accelerator card; non MAC-related
>> dataflow is PCIe from there. Buffering re
On 04/06/2010 09:44 PM, John Gilmore wrote:
>> Which part of the Linux issue... sustained throughput or latency? I
>> wouldn't be surprised to find that latency hasn't
>> improved substantially because it's not a priority for server software.
>> Even VoIP applications are not concerned
>> about
> Which part of the Linux issue... sustained throughput or latency? I wouldn't
> be surprised to find that latency hasn't
> improved substantially because it's not a priority for server software. Even
> VoIP applications are not concerned
> about a 1 msec improvement... whereas that makes or br
Hi Veljko,
> What I got from your paper is that the matched filter approach for
> fast packet detection would not work in an OFDM setting. What about
> fast ACK generation? Would it require an IFFT implementation on the
> USRP? Would it help much?
>
It's a good question, and something I haven't
PS. if you haven't seen, SORA is able to interoperate with 802.11g, which
is impressive. It meets all of the timing requirements. However, it does
not come with the exact ease of programming that we're familiar with. They
do have to push the use of SSE and tradeoff a lot of computation for memo
>
> Did you see my previous post about the accelerator PCIe card? To some
> extent the Microsoft approach is what we're
> doing. But we want to stay compatible with USRP2 hardware so we connect
> GbE to the accelerator card; non MAC-related
> dataflow is PCIe from there. Buffering required to st
On Tue, Apr 6, 2010 at 5:35 PM, Jeff Brower wrote:
> Philip-
>
> > On 04/06/2010 04:19 PM, George Nychis wrote:
> >> Jeff, I definitely agree that buffering also adds significant latency.
> How
> >> much of the MAC can you get around? I just think that, there are a
> number
> >> of people who w
Charles-
>> I would tend to blame Linux and buffering more than GbE itself (MAC + PHY).
>> Here is an interesting doc where the
>> researchers were asking similar questions:
>>
>> http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf
>>
>> I'm not sure yet how much buffering is d
Philip-
> On 04/06/2010 04:19 PM, George Nychis wrote:
>> Jeff, I definitely agree that buffering also adds significant latency. How
>> much of the MAC can you get around? I just think that, there are a number
>> of people who want the flexibility of the SDR, but want to do MAC research,
>> and
George-
> Jeff, I definitely agree that buffering also adds significant latency. How
> much of the MAC can you get around? I just think that, there are a number
> of people who want the flexibility of the SDR, but want to do MAC research,
> and current common SDR architecture is just not good en
Hi George,
2010/4/6 George Nychis :
> Jeff, I definitely agree that buffering also adds significant latency. How
> much of the MAC can you get around? I just think that, there are a number
> of people who want the flexibility of the SDR, but want to do MAC research,
> and current common SDR arch
On 04/06/2010 04:19 PM, George Nychis wrote:
Jeff, I definitely agree that buffering also adds significant latency. How
much of the MAC can you get around? I just think that, there are a number
of people who want the flexibility of the SDR, but want to do MAC research,
and current common SDR ar
Jeff, I definitely agree that buffering also adds significant latency. How
much of the MAC can you get around? I just think that, there are a number
of people who want the flexibility of the SDR, but want to do MAC research,
and current common SDR architecture is just not good enough. We need lo
> I would tend to blame Linux and buffering more than GbE itself (MAC + PHY).
> Here is an interesting doc where the
> researchers were asking similar questions:
>
> http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf
>
> I'm not sure yet how much buffering is done in the USRP2
Two independent PC+USRP nodes. All the ACK related logic was
implemented at the Python layer.
Another thing that I tried was to connect the two nodes via Ethernet
(I have two Ethernet NICs in each of the PCs) and then use USRPs for
data and Ethernet for ACKs. I still couldn't get good results,
alt
Veljko-
> I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but
> the delay was too long and inconsistent. I can't remember the exact
> figures, but definitely up to milliseconds.
Do you mean two USRP2s back-to-back? Or both connected to motherboard ports?
-Jeff
> 2010/4/6 George
I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but
the delay was too long and inconsistent. I can't remember the exact
figures, but definitely up to milliseconds.
Veljko
2010/4/6 George Nychis :
>
>
> On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick wrote:
>>
>> Thanks for the rep
George-
>> Thanks for the reply George. I'm still looking for a little more
>> information on this topic.
>>
>> - What is PMT
>
> http://gnuradio.org/redmine/wiki/1/TypePMT
>
>> - Why was m-block removed
>
> http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html
>
>> - Has anyone measured
On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick wrote:
> Thanks for the reply George. I'm still looking for a little more
> information on this topic.
>
> - What is PMT
>
http://gnuradio.org/redmine/wiki/1/TypePMT
> - Why was m-block removed
>
http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/m
Thanks for the reply George. I'm still looking for a little more
information on this topic.
- What is PMT
- Why was m-block removed
- Has anyone measured latency with the USRP2 and GigE
- Is GigE alone not capable of handling MAC turnaround times or is
software to blame for this
- Is the scheduler
Think of it this way...
MAC *development* is severely limited by GNU Radio... it lacks the
much-needed functionality to make information passing between the
blocks rich, simple, and bi-directional. Some of the building blocks
are in place (e.g., PMT), and the m-block was implemented to solve the
I've been reading some papers related to MAC layer development on the
USRP, but they seem to have tapered off with the USRP2. Does anyone
have any information about MAC layer and protocol development for the
USRP2. Has this been satisfied with things like timestamps and gigE?
Any current papers or
27 matches
Mail list logo
