Image Map Image Map
Page 4 of 8 FirstFirst 12345678 LastLast
Results 31 to 40 of 72

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,638

    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
    120

    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,638

    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.

  10. #40
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,638

    Default

    Hello again. Since I last poked into this thread I've installed a Realtek 8019A Ethernet card in my Tandy 1000, and it's starting to look to me like I may have been wrong to blame EPPPD for the issue I was seeing with the mTCP FTP client? It seems at least like my packet driver is working fine; the DHCP client works, as does SNTP. But I'm still seeing the same issue with FTP, at least with the server I've tried it against, ftp.oldskool.org. Connecting and navigation seem fine, but if I try to fetch a file larger than the FTP buffer defined in the mtcp configuration file the transfer just grinds to a halt and never completes. (I've tried leaving it for a *long* time and it looks like eventually the server just times out and disconnect. I haven't tcpdumped it yet, however, because it's significantly less easy to do so with the connection going straight to the ethernet switch instead of through the laptop.)

    I've tried an old WATTCP-based FTP client against the same server and it seems to work fine. I'm puzzled why I'm having these issues on the Tandy 1000 since these programs apparently work fine on a PCjr. Would you be interested in a trace of an attempted download session to look at? I haven't done a lot with the card yet, perhaps I should try hitting some more servers (and try some large http gets again, since that also seemed to be an issue when I was using EPPPD ***) before I can say definitively that the problem is between this machine and mTCP rather than some server problem.

    (***) Edit: I just tried using htget.exe to re-fetch the 2015 versions of the programs from www.brutman.com and it worked fine to get the 600k zip file (was surprisingly fast, honestly), so it seems to just be the FTP client? Or just that server. I'll poke around for other servers to try.

    (!!!) Edit #2: Okay, I just tried ftp-ing a 1.4MB file from ftp.zimmers.net and the transfer worked absolutely fine. So... NEVER MIND, apparently! (Is anyone else trying to hit ftp.oldskool.org with this? Weird.)
    Last edited by Eudimorphodon; November 19th, 2019 at 06:44 PM.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

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
  •