• Please review our updated Terms and Rules here

NTCPDRV lockup bug workaround

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
the nasty lockup bug when running a server (it's been acknowledged by peter tattam) now has a workaround that i've found. i keep a linux machine pinging my 8088 every few seconds over my LAN. it keeps the packets processing.

mr. tattam can't seem to fix it and he's working on it still to this day. this is hardly an ideal solution, but it works. my 8088 has now been up for over 36 hours running my "quikserv" Http/ftp server program with at least 10 internet connections incoming per hour, and a myriad more from my computers on the LAN. compare that to the normal 1 hour or less before it locked up.

http://www.8088online.com (i'm sure you guys have that memorized by now)

not really much content.. just making sure it stays working. hopefully will have a hard disk soon. my ZIP disk is wayyy too slow on that machine to do it.

my 286 IRC server is also now running stable on port 6668. want to see if it can stay up a week before i make it the main port 6667 server. but yes, it seems as if this horrible issue has been resolved... i wish there were a better way to do it, but hey whatever works i guess.

i'll stop here since you're all sick of my 8088 web server posts. :)
 
Last edited:
"i'll stop here since you're all sick of my 8088 web server posts"

Not really. :) ... but I'm waiting for the WATTCP version to come out. What's wierd is that it works from some clients and not from others. The http server doesn't work from an XP/Firefox machine in this house but on Linux machines it works with any number of browsers, including Firefox. I thought all browsers would be making the same requests. (shows you what I know)
 
"i'll stop here since you're all sick of my 8088 web server posts"

Not really. :) ... but I'm waiting for the WATTCP version to come out. What's wierd is that it works from some clients and not from others. The http server doesn't work from an XP/Firefox machine in this house but on Linux machines it works with any number of browsers, including Firefox. I thought all browsers would be making the same requests. (shows you what I know)

btw about WATTCP, i'm steadily learning C++ right now so i plan to eventually do a re-write on the server in Turbo C on top of the WATTCP code. as of now, with QB, the best option really is NTCPDRV because the WATTCP TSR interface only handles 6 connections maximum. i can use 28 in NTCPDRV.

also, i am in the middle of adding "module" support to QUIKSERV.. as in CGI-type stuff. it isn't exactly CGI, as DOS environment variables are limited to uppercase so i can't really give a QUERY_STRING variable without it changing lowercase to caps. what i'm developing works exactly like CGI, except all the input and variable are found by the module in a file instead.

when this is all done i'll be releasing a new version, along with instructions on programming your own customized modules; along with the program coming with a few of my own like a comment module and probably a file upload module.
 
MC: "that's pretty strange. i have no problems with windows machines."

Even stranger: from the XT machine it doesn't work with Firefox but it works just fine with the otherwise buggy IE. I'd never tried it before because of its bad reputation but it works.

I'll go upstairs right now and try your comment applet from the XT box.
 
your comments are all there! you'll notice the timestamps are off on a lot of posts lol. i need a clock card for that thing. i could just put my little LAN time client on it and have it run in autoexec too, that'd work. it's annoying when the posts say "timestamp: 10-26-2078" :p
 
so i installed a second network card in the 8088, and am using it as an interface for network storage.. no more hosting the sites on a floppy! :)

it's quite fast for what it is, go check out the website now and you can see a huge increase in transfer rate + an even bigger increase in responsiveness.
 
It's funny you mention that. I had a funny idea to cluster my PCjrs running their (future) telnet BBS, and use just one machine as a 'backend' for handling the message board and user file. Not quite the same as what you are doing, but it would provide for more concurrent users and it would probably be faster because the backend machine could use the memory as a cache.

I still want to keep it all on vintage hardware. I'm willing to cheat a little bit by using a parallel attached SCSI drive or Zip drive. The Zip drive probably isn't a great solution - I don't think they were meant to be used as substitute hard drives.
 
It's funny you mention that. I had a funny idea to cluster my PCjrs running their (future) telnet BBS, and use just one machine as a 'backend' for handling the message board and user file. Not quite the same as what you are doing, but it would provide for more concurrent users and it would probably be faster because the backend machine could use the memory as a cache.

I still want to keep it all on vintage hardware. I'm willing to cheat a little bit by using a parallel attached SCSI drive or Zip drive. The Zip drive probably isn't a great solution - I don't think they were meant to be used as substitute hard drives.

writing to my ZIP drive is incredibly slow... not what i thought it'd be like when i ordered the thing. 8088's just can't handle them quick enough to be a substitute hard drive. it reads very fast though.

not a bad idea to keep one of those for a backend. although i don't think you should worry quite as much about the memory as you are. how much RAM does it have again? 640 KB? or is it 512...
 
As slow as a Zip drive is, it is far faster than a floppy drive. They seek faster, have better transfer rates, and are a heck of a lot bigger. I've measured 16KB per second on a PCjr equipped with a bi-directional parallel port. The best a floppy drive can do is 11KB per second. (This is with sequential reads and writes.)

My machine has 640K, but it is effectively more like 512K. I have over 256K to play with so I'm sandbagging a little bit, but I really do want to conserve the memory for things like caching important files, TCP buffer space, etc.
 
As slow as a Zip drive is, it is far faster than a floppy drive. They seek faster, have better transfer rates, and are a heck of a lot bigger. I've measured 16KB per second on a PCjr equipped with a bi-directional parallel port. The best a floppy drive can do is 11KB per second. (This is with sequential reads and writes.)

My machine has 640K, but it is effectively more like 512K. I have over 256K to play with so I'm sandbagging a little bit, but I really do want to conserve the memory for things like caching important files, TCP buffer space, etc.

reading files from the ZIP on a 4.77 MHz i get about 20+ KB/s - for some reason, using the palmzip driver writing is about 2 or 3 KB/s.
 
Back
Top