[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] more gmsk issues

From: Greg Troxel
Subject: Re: [Discuss-gnuradio] more gmsk issues
Date: Tue, 23 Jan 2007 11:09:10 -0500
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (berkeley-unix)

"Brett L. Trotter" <address@hidden> writes:

> I saw the fragments not making it, but by didn't see anything of note, I
> meant I didn't see anything that caused that condition.

You really should have explained what you found; in debugging it's
critical to share all the facts.

>> Could you set the MTU to avoid fragmentation, perhaps to 576 (ip
>> bytes)?  Or try scping a file, which will/should adapt MSS to MTU
> scp was the first thing we tried and that locks up similarly- even SSH
> locks up after a certain amount of traffic (catting /dev/urandom through
> strings to generate traffic). That's why I started investigating UDP
> mechanisms thinking perhaps TCP was bad over the USRP/gmsk.

So what is "certain amount"?  How does that vary?   Can you start a
new transfer without restarting GNU Radio?   What packet sizes are
observed with scp?  Is there fragmentation?

>> The last 2nd fragment (meaning offset 480) is id 32558, so it seems
>> that your system in getting in a state where the second fragment is
>> always dropped.  Is there some queue which is always full or nearly
>> full and therefore when 2 back-to-back frames get sent the second is
>> always dropped?  Using TCP may avoid this problem, since it will back
>> off more aggressively.
>> It may be that you are finding bugs in your system's fragment
>> reassembly code.
> I hope not, there'd be no way for me to fix it. This is on Fedora Core 6
> x86_64 running on an FX-60 dual core 2.6 GHz w/ 2GB ram.

So far, it looks to me like the system gets in a mode where it drops
2nd fragments, and that's the root cause.  But you'll have to be far
more methodical and report far more details if this is to be figured

I think you really should set MTU (and perhaps TCP MSS or packet size
in FSP) to avoid IP fragmentation.  IP fragmentation is generally
recognized as a bad idea and something to be avoided.

Attachment: pgpmtRKmj4C9j.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]