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 required to
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
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 concerned
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 that makes
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
On Wed, Apr 7, 2010 at 4:54 PM, Per Zetterberg per.zetterb...@ee.kth.sewrote:
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
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
On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick cir...@gmail.com 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
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 latency with the
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 gnyc...@cmu.edu:
On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick cir...@gmail.com
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
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,
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
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
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
Hi George,
2010/4/6 George Nychis gnyc...@cmu.edu:
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
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
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 current
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 done in the
On Tue, Apr 6, 2010 at 5:35 PM, Jeff Brower jbro...@signalogic.com 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
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 stay
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
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
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 breaks
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 a 1 msec
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
26 matches
Mail list logo
