Patrick Strasser wrote:
>
> Some more notes... It's been very late when writing this.
>
> Patrick Strasser wrote:
>> In general TCP is quite capable
>> of recovering from lots of errors, but it's busy with itself for this
>> purpose, which leaves less capacity for its payload. IP does not correct
>> errors, only detects (checksums). This leaves possible error correction
>> to layer 2 and 1.
>
> Of course the application has to take care of errors. If some errors
> survive the application has to cope. Some do not care at all, like video
> and audio streams: If data is lost, no retransmission is tried. The
> human brain has to interpolate missing information and thus do the error
> correction.
>
>> In layer 2 we have a mixture of Ethernet and a back
>> off algorithm[..]
> > Note:
>> AFAICS check for successful transmission is done.
> ^^^^
> Of course I meant "_No_ check for successful transmission is done."
>
> Patrick
> --
> Engineers motto: cheap, good, fast: choose any two
> Patrick Strasser <patrick dot strasser at tugraz dot at>
> Student of Telematik, Techn. University Graz, Austria
>
>
I appreciate all of your insightful comments, but here's where I'm confused.
NFS, FSP, and TFTP all use UDP and should have acknowledgement, verification
and resend capability- and all of those seem to get tied up after X bytes of
transfer, depending on MTU, bitrate, etc. It seems that for a given setting,
I can only transfer a very specific number of bytes of data. Before, during,
and after the transfer, I can ping with 1k payloads until the end of time-
and despite the fact that FSP and TFTP don't create a connection of any
kind, they get bogged down like SCP did when I was trying TCP transports.
So the bottom line question is why in the heck would a file transfer over a
stateless protocol get frozen after a certain number of bytes when it
appears I can ping with large payloads indefinitely?
For the record, anything terribly deep in python or networking code is
beyond me- so aside from simple settings tweaks and protocol/application
selection to garner stability, I'm probably out of my league.
--
View this message in context:
http://www.nabble.com/more-gmsk-issues-tf3043203.html#a8502777
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio