Image Map Image Map
Page 4 of 4 FirstFirst 1234
Results 31 to 39 of 39

Thread: mTCP updates coming soon: Send me your bug reports

  1. #31

    Default

    Recursive mget is not going to happen any time soon - for reasonably sized directory hierarchies it can work but if somebody goes bananas there is a deeply nested tree of files memory becomes an issue very fast, and dealing with out of memory situations gracefully is a pain. My work-around is to use zip files, and yes, I know this doesn't work unless you have room for the zip file already.

    Preserving timestamps should be doable. That's just an optional capability I can add.

    maxtherabbit: What does the output from the packet driver loading look like after the soft reset? Nothing mTCP does can survive a reboot, but there might be some crappy state left in the card that is not being flushed out. You might want to try a different version of the packet driver. (Also, send me a trace of when it fails.)

  2. #32

    Default

    The console output of the packet driver's init is the same in either case. I have no idea how to attach a debugger to a DOS process lol

  3. #33

    Default

    Read the documentation in the PDF file - there are instructions for how to collect a trace from mTCP programs.

  4. #34

    Default

    Quote Originally Posted by mbbrutman View Post
    Read the documentation in the PDF file - there are instructions for how to collect a trace from mTCP programs.
    I've attached the trace to this post, but I doubt it will be helpful - it appears that your software is working fine but the packet driver just isn't passing packets

    dhcptrace.txt

  5. #35
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,465

    Default

    I don't know if this counts as a bug report, exactly, but I do seem to be having issues with the FTP and HTGET programs over PPP from an XT-class machine. The TL;DR version is, using FTP as an example, is I'll attempt to "get" a file from the remote server, and usually a fairly short period of time later "Bytes Transferred: 8196" will appear after the "150" status update, but from that point the transfer seems to start falling apart.

    I've done a bit of TCPdump-ing of the 'ppp0' interface on the Linux machine at the other end, and it looks like what happens is after a certain number of packets sent/received something starts dropping packets on the XT's end; I'll start seeing spews of duplicate acks, and then re-transmits from the server end, and then *something* bogs down so badly I'll start to see fairly long periods of silence, followed by what seems to be a repeated packet of data, followed by some duplicate acks... eventually I might even see an "FTP: 226 Transfer Complete" message sent from the server, but that will inevitably be followed by a long pause, more retransmits... I think in the last one I dumped I actually saw the server send a packet to close the control connection, but the client stayed stuck on the "bytes transferred" status.

    If the file is under... 20k-ish it will usually succeed. (If it's under 10k it might actually complete quickly.)

    So far as I can tell the "Telnet" program works fine (I've hit a few Internet BBSs and they all seem to do a fine job displaying pretty ANSI graphics), but I haven't tried any file transfers with it. It feels like some kind of a buffer is filling up and once it does everything goes pear shaped. Is EPPPD simply too slow on an XT class machine to adequately emulate a network card?

  6. #36
    Join Date
    Dec 2012
    Location
    Russia, Moscow
    Posts
    113

    Default

    Maybe implement EMS support for HTTPServ (caching)?

  7. #37

    Default

    I have to test EPPPD again to refresh my memory but my impression of it at the time was that it did not work well under load. Especially when using an 8250 UART; there is no room for error because it can hold just one byte.

    You might try setting the MTU size to be 576. (A smaller MTU will make the re-transmit logic more responsive.) You can go lower than 576 but it can cause fragmented packets for things like DNS, which should work but it is not a well tested path.

  8. #38

    Default

    Quote Originally Posted by Tronix View Post
    Maybe implement EMS support for HTTPServ (caching)?
    I've thought about either EMS or extended memory. EMS is probably a better idea - even the XT class machines can use it (assuming a suitable card is installed). I'll add it to the list.

  9. #39
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,465

    Default

    Quote Originally Posted by mbbrutman View Post
    I have to test EPPPD again to refresh my memory but my impression of it at the time was that it did not work well under load. Especially when using an 8250 UART; there is no room for error because it can hold just one byte.
    The serial card I'm using has a 16550 compatible UART (a 16552D), but I guess I don't know if EPPPD is actually leveraging it or not, it doesn't seem to spit out much in the way of diagnostic info. I've tested the port doing file transfers with KERMIT and a thing I've observed is that with that the effective transfer speed seems to top out at around 2000 characters per second. (IE, I get no reported errors if I run at 115200, but at the end of the transfer Kermit will tell me it was approximately "16% efficient"; lower speeds will simply increase that percentage until you get to 19200, at which point it's maxxed.) Likewise I don't know if Kermit is detecting/using the 16550 magic, perhaps there's a way to get that information out of it, but it seems like handshaking is at least working.

    I've been using 576 as the MTU size. I spent some time fooling with lowering the baud rate, but it seems to behave about the same at 9600 as it did at 115200. (Maybe I should try going *really* slow?) Since Telnet seems to work fine I was wondering if it could be some interaction/incompatibility with my XT-CF card, IE, it's bogging down trying to write the data to disk?

    In *one* attempt to use the FTP program it did seem to do fine downloading a 100k-ish file from a slow, laggy, high-latency server in Germany. I'm kind of tempted to play with some net-shaping software and tweak it so the link on the upstream computer emulates a high-latency ISDN-speed line.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •