Re: [Discuss-gnuradio] more gmsk issues

[Greg Troxel]

"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
out.

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.

pgpmtRKmj4C9j.pgp
Description: PGP signature