chad5200 Posted February 4 Share Posted February 4 I have been playing around with Carina II BBS software lately with SpartaDos 3.2Z. I have an Atari 800XL with Ultimate 1MB with latest firmware. Carina is very modular with many Basic programs that RUN each other. I am using Atari BASIC rev C. Something I have been experiencing occasionally is one BASIC program tries to RUN another BASIC program... but the new program does not fully load. It's like it is experiencing a timeout in the middle of the load. Obviously, this causes the program to fail and everything stops. When I LIST the program, the first part of the program lists fine but at some point the listing turns to garbage. I reboot, try again, and everything is fine. So it's only happening occasionally. I have my ATR's mounted via my own local TNFS server. I am running the latest FujiNet firmware. I am wondering a network "hiccup" would cause this behavior? Or maybe if the TNFS host is "busy" for a couple seconds during a FujiNet disk read might do this? Possibly a timeout of some sort? I am looking for any suggestions as where to look. Is there a timeout limit during a disk read on the Atari? If so, are there any settings to help counter this? A "read retry" setting or something? Thanks, Chad Quote Link to comment Share on other sites More sharing options...
mozzwald Posted February 4 Share Posted February 4 It could be a network hiccup. If you hookup FujiNet to a computer and capture the debug output it will show what's happening and you might see there is a tnfs timeout. https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 4 Author Share Posted February 4 4 hours ago, mozzwald said: It could be a network hiccup. If you hookup FujiNet to a computer and capture the debug output it will show what's happening and you might see there is a tnfs timeout. https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output I have been able to replicate the issue. What I did was take a 14KB BASIC program and named it GATETEST. At the very beginning, I have it GOTO a line near the end. Then at that line near the end, I have it PRINT "X"; so I know it's running... and then the command RUN "D:GATETEST". So now it keeps LOADing and RUNning over and over and PRINTing "X" each time and will go forever until there is an issue. Then, on my PC where I am running the TNFS server, I perform a somewhat intensive procedure to give the PC a workload. You can eventually hear the SIO bus struggling a bit. Then soon enough I get an ERROR 12 in BASIC... meaning it's trying to GOTO a line that does not exist. Now when I do a LIST, the program LISTs OK for a while and then turns into garbage. Problem is been successfully reproduced on demand! The BASIC program has half loaded into memory. Here is the part from the debug log that relates to when the error happens: [15:15:16] [15:15:16] CF: 31 52 f4 21 99 [15:15:16] disk sio_process() [15:15:16] ACK! [15:15:16] ATR READ [15:15:17] Timeout after 1000 milliseconds. Retrying [15:15:18] TNFS OUT OF ORDER SEQUENCE! RETRYING [15:15:18] ->SIO write 256 bytes [15:15:18] COMPLETE! [15:15:18] Attached is the entire debug log. Other than "hey, don't run your TNFS server on a PC that might be somewhat busy occasionally" (which is perfectly acceptable solution)... is there anything I can do? Any tricks, workarounds, buffer adjustments, timeout adjustments, etc? Anyway to prevent the "TNFS OUT OF ORDER SEQUENCE" from happening? I would prefer to keep using my PC as the TNFS server. I suppose I could put the BBS files on the FujiNet's SD card, but then I am constantly fiddling with an SD card when I want to get updated BASIC BBS code on there. Anyways, any tips or thoughts would help. Thanks for all your help! Chad FujiNet-debug-BASIC-LOAD-TEST.txt 2 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted February 5 Share Posted February 5 Now that is how to report a bug! Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 5 Share Posted February 5 On 2/4/2023 at 9:38 PM, chad5200 said: I have been able to replicate the issue. What I did was take a 14KB BASIC program and named it GATETEST. At the very beginning, I have it GOTO a line near the end. Then at that line near the end, I have it PRINT "X"; so I know it's running... and then the command RUN "D:GATETEST". So now it keeps LOADing and RUNning over and over and PRINTing "X" each time and will go forever until there is an issue. I have had a quick look at your log file and apart from a few checksum errors and the obvious TNFS OUT OF ORDER SEQUENCE I am not sure what's going on yet. Could you please post your GATETEST file and I will try to compare it on my installation for comparison. What DOS do you run? Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 5 Author Share Posted February 5 41 minutes ago, TZJB said: I have had a quick look at your log file and apart from a few checksum errors and the obvious TNFS OUT OF ORDER SEQUENCE I am not sure what's going on yet. Could you please post your GATETEST file and I will try to compare it on my installation for comparison. What DOS do you run? It's SpartaDos 3.2Z. I have attached a bootable ATR for testing with. Boot this ATR and make sure BASIC is enabled. Then just RUN "D:GATETEST". As you can see in the LISTing, it has: 1 GOTO 31010 (a bunch of BASIC code) 31010 ? "X ";:RUN "D:GATETEST" Then try to stress your PC a little bit to force the issue. Sometimes I don't even need to purposely stress the PC, the PC occasionally does a background thing that stresses itself. When you get the ERROR 12, do a LIST to see how it didn't load correctly and garbage is presented at some point in the listing. Thanks for investigating! Chad GATETEST-SpartaDos32z.atr Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 5 Share Posted February 5 2 minutes ago, chad5200 said: It's SpartaDos 3.2Z. I have attached a bootable ATR for testing with. Boot this ATR and make sure BASIC is enabled. Then just RUN "D:GATETEST". As you can see in the LISTing, it has: 1 GOTO 31010 (a bunch of BASIC code) 31010 ? "X ";:RUN "D:GATETEST" Then try to stress your PC a little bit to force the issue. Sometimes I don't even need to purposely stress the PC, the PC occasionally does a background thing that stresses itself. When you get the ERROR 12, do a LIST to see how it didn't load correctly and garbage is presented at some point in the listing. Thanks for investigating! Chad GATETEST-SpartaDos32z.atr 359.64 kB · 0 downloads You are welcome. Incidentally what PC are you running the server on? I have an old Core i3-2120 16GB DDR3 RAM running all sorts of processes all at once. Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 5 Author Share Posted February 5 19 minutes ago, TZJB said: Incidentally what PC are you running the server on? It's hardware I purchased in 2016 or 2107. Still performing quite well. AMD FX-6300 Six-Core Processor 3.50 GHz. 32GB RAM. SSD hard drives. Connected directly to wireless router via ethernet cable. Windows 10. Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 6 Share Posted February 6 9 hours ago, chad5200 said: It's hardware I purchased in 2016 or 2107. Still performing quite well. AMD FX-6300 Six-Core Processor 3.50 GHz. 32GB RAM. SSD hard drives. Connected directly to wireless router via ethernet cable. Windows 10. That seems a much higher spec than mine. However it would seem that you do have a problem. My server is also directly connected to the router with a Gigabit Ethernet connection and the Fujinet is within line of sight of the router at a distance of 15-16 feet. My 800XL has 256K RAM a V4 OS and Basic Rev C I used IntelBurnTest to stress the server while performing it's other duties and CPUID HWmonitor to check the power and temperatures. At no time did the GATETEST fail. Results:- Server processor normal power use and temperature is 15W 40C 104F @ 1.6-3.3MHZ and has Windows 10 professional x64. Intel Burn Test v2.54 Stress Level Standard - No failures 43.75W 62C 143F @ 3.3 MHz Intel Burn Test v2.54 Stress Level High - No failures 43.77W 63C 145F @ 3.3 MHz Intel Burn Test v2.54 Stress Level Very High - No failures 43.75W 64C 147F @ 3.3 MHz Intel Burn Test v2.54 Stress Level Maximum - No failures 46.17W 64C 147F @ 3.3 MHz Just a thought, is your TNFS folder on the same drive as your operating system as this may affect the performance? Mine is a seperate drive. Incidentally Intel Burn Test will run on AMD processors if you would like to try it, what did you use? Please see the Fujinet logs attached for a comparison to yours. I didn't notice until the end, but the SD card was out and the logs show this. GATETEST1.Burnteststandard.txt GATETEST2.Burntesthigh.txt GATETEST3.Burntestveryhigh.txt GATETEST4.Burntestmax.txt Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 6 Author Share Posted February 6 4 hours ago, TZJB said: Just a thought, is your TNFS folder on the same drive as your operating system as this may affect the performance? My TNFS was on the save physical drive as the OS. I just tried moving it to a completely separate drive but still the same result. The frustrating thing is, I don't even need to run something that purposely stresses my PC. In fact, the last time it happened, I had Task Manager's Performance tab running and it showed nothing out of the ordinary. In the meantime, I have set up a Raspberry Pi to run TNFS as detailed here: https://atari8bit.net/projects/software/fujinet-tnfs-server-image/ I'm having good luck with the Pi so far. I will continue to use this set up now. I do like how I don't need to have the PC running for the TNFS and yet it's easily accessible from the PC when needed to add/remove files. Until further information comes along, I guess we can chalk it up to some oddity with my PC? Thanks again for all your help! Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 6 Share Posted February 6 1 hour ago, chad5200 said: My TNFS was on the save physical drive as the OS. I just tried moving it to a completely separate drive but still the same result. The frustrating thing is, I don't even need to run something that purposely stresses my PC. In fact, the last time it happened, I had Task Manager's Performance tab running and it showed nothing out of the ordinary. In the meantime, I have set up a Raspberry Pi to run TNFS as detailed here: https://atari8bit.net/projects/software/fujinet-tnfs-server-image/ I'm having good luck with the Pi so far. I will continue to use this set up now. I do like how I don't need to have the PC running for the TNFS and yet it's easily accessible from the PC when needed to add/remove files. Until further information comes along, I guess we can chalk it up to some oddity with my PC? Thanks again for all your help! You are welcome. It was worth trying to duplicate the problem elsewhere. If the Pi is working reliably it does point towards your PC being the problem however, if not, you may have a WiFi problem. Is there much interference in your WiFi 2.4 GHz range? Netspot Free is a useful PC/Mac tool if you have a laptop to run a WiFi survey, and is also available for mobile devices apparently. Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 6 Author Share Posted February 6 6 hours ago, TZJB said: Is there much interference in your WiFi 2.4 GHz range? Netspot Free is a useful PC/Mac tool if you have a laptop to run a WiFi survey, and is also available for mobile devices apparently. My WiFi is good. In fact, my FujiNet is only about 2 feet away from the WiFi router. Checked out Netspot Free and it looks good there too. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted February 6 Share Posted February 6 you might be too close. try moving further away or creating and obstruction of some kind. This does happen, DIRECTV genies had a problem with being to close and it's one of the solutions for that as well. Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 7 Share Posted February 7 18 hours ago, _The Doctor__ said: you might be too close. try moving further away or creating and obstruction of some kind. This does happen, DIRECTV genies had a problem with being to close and it's one of the solutions for that as well. That's a good point. @chad5200 you might be microwaving your poor Fujinet and Atari 800XL as 2.4GHz is the same frequency as a microwave oven! Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 7 Author Share Posted February 7 Hmmm. I guess it's good that I am done having children. I'll rearrange the setup a little bit. You're right, I looked into it and it sounds like the Wi-Fi router should be at least 10 feet away from electronic devices and people. Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 7 Share Posted February 7 1 minute ago, chad5200 said: Hmmm. I guess it's good that I am done having children. I'll rearrange the setup a little bit. You're right, I looked into it and it sounds like the Wi-Fi router should be at least 10 feet away from electronic devices and people. I forgot about microwaving yourself! 1 Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 8 Author Share Posted February 8 7 hours ago, TZJB said: I forgot about microwaving yourself! I have moved my router. It's now about 10 feet away. Still can reproduce the same issue. The quickest way for me to reproduce is to load a modern game on my PC while running that GATETEST program. I am wondering if it is all the disk activity, and not the CPU activity, that causes the issue? I see the line in the code referencing the error message from my log... "TNFS OUT OF ORDER SEQUENCE! RETRYING" https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/TNFSlib/tnfslib.cpp#L1250 I guess my question now is... if the code can detect an "out of order sequence" and report on it, can it also correct for it on the fly? Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 8 Share Posted February 8 11 hours ago, chad5200 said: I have moved my router. It's now about 10 feet away. Still can reproduce the same issue. The quickest way for me to reproduce is to load a modern game on my PC while running that GATETEST program. I am wondering if it is all the disk activity, and not the CPU activity, that causes the issue? I see the line in the code referencing the error message from my log... "TNFS OUT OF ORDER SEQUENCE! RETRYING" https://github.com/FujiNetWIFI/fujinet-platformio/blob/master/lib/TNFSlib/tnfslib.cpp#L1250 I guess my question now is... if the code can detect an "out of order sequence" and report on it, can it also correct for it on the fly? I'm glad that you are OK and have not microwaved yourself too much! Generally speaking you would not want to run a game on a server! This could be the problem as all of the computer's resources are probably being used by the game, so this could be causing you a false flag. Did you try a more normal test like the Intel Burn Test? A burn in test uses the disk less but stresses everything else so would prove stability of the main board and components. Is your boot drive an SSD as this can help with performance? Regarding the TNFS server, there is not much information that I can quickly find about it other than it uses the UDP protocol, which is fast but not error corrected. The OUT OF ORDER SEQUENCE is from a read command according to your previous log which would indicate that the TNFS server is being inhibited from communication for that 1 second delay to occur. My advice is to not run games on a server 😉. Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 8 Author Share Posted February 8 (edited) 1 hour ago, TZJB said: My advice is to not run games on a server Totally understood and I already have a dedicated Raspberry Pi in place to be my TNFS host. The frustrating thing is that this will happen when my PC is doing "nothing" also. It's just that I can help force the situation (for testing purposes) by running a game. But, I am curious to know if this can be corrected in the FujiNet code. It appears that the code KNOWS that it received an "TNFS OUT OF ORDER SEQUENCE! RETRYING" but is sometimes not correcting the packet it should attempt to re-read and instead is just continuing on with the next packet and of course this causes the Atari to receive a corrupted file transfer. Consider this... Here is a new capture of the same GATETEST but this time I am running the IntelBurnTest v.2.54 on Standard Stress Level. I am only sharing the relevant part where I activate the IntelBurnTest. Spoiler [08:22:29] CF: 31 52 7c 00 ff [08:22:29] disk sio_process() [08:22:29] ACK! [08:22:29] ATR READ [08:22:29] ->SIO write 256 bytes [08:22:29] COMPLETE! [08:22:29] [08:22:29] CF: 31 52 7d 00 01 [08:22:29] disk sio_process() [08:22:29] ACK! [08:22:29] ATR READ [08:22:29] ->SIO write 256 bytes [08:22:29] COMPLETE! [08:22:29] [08:22:29] CF: 31 52 7e 00 02 [08:22:29] disk sio_process() [08:22:29] ACK! [08:22:29] ATR READ [08:22:29] ->SIO write 256 bytes [08:22:29] COMPLETE! [08:22:29] [08:22:29] CF: 31 52 7f 00 03 [08:22:29] disk sio_process() [08:22:29] ACK! [08:22:29] ATR READ [08:22:30] Timeout after 1000 milliseconds. Retrying [08:22:31] TNFS OUT OF ORDER SEQUENCE! RETRYING [08:22:32] Timeout after 1000 milliseconds. Retrying [08:22:34] TNFS OUT OF ORDER SEQUENCE! RETRYING [08:22:34] Timeout after 1000 milliseconds. Retrying [08:22:35] Retry attempts failed [08:22:35] _tnfs_fill_cache received failure condition on TNFS read attempt [08:22:35] tnfs_read cache fill failed (4294967295) - aborting->SIO write 256 bytes [08:22:35] ERROR! [08:22:35] [08:22:35] CF: 31 52 7f 00 03 [08:22:35] disk sio_process() [08:22:35] ACK! [08:22:35] ATR READ [08:22:35] tnfs_lseek currpos=31888, pos=0, typ=1 [08:22:36] Timeout after 1000 milliseconds. Retrying [08:22:38] Timeout after 1000 milliseconds. Retrying [08:22:40] Timeout after 1000 milliseconds. Retrying [08:22:41] Retry attempts failed [08:22:41] tnfs_lseek currpos=31888, pos=31888, typ=0 [08:22:42] Timeout after 1000 milliseconds. Retrying [08:22:44] Timeout after 1000 milliseconds. Retrying [08:22:46] Timeout after 1000 milliseconds. Retrying [08:22:47] Retry attempts failed [08:22:47] ->SIO write 256 bytes [08:22:47] ERROR! [08:22:47] [08:22:47] CF: 31 52 7f 00 03 [08:22:47] disk sio_process() [08:22:47] ACK! [08:22:47] ATR READ [08:22:47] tnfs_lseek currpos=31888, pos=31888, typ=0 [08:22:48] Timeout after 1000 milliseconds. Retrying [08:22:50] Timeout after 1000 milliseconds. Retrying [08:22:52] Timeout after 1000 milliseconds. Retrying [08:22:53] Retry attempts failed [08:22:53] ->SIO write 256 bytes [08:22:53] ERROR! [08:22:53] [08:22:53] CF: 31 52 7f 00 03 [08:22:53] disk sio_process() [08:22:53] ACK! [08:22:53] ATR READ [08:22:53] tnfs_lseek currpos=31888, pos=31888, typ=0 [08:22:54] Timeout after 1000 milliseconds. Retrying [08:22:56] TNFS OUT OF ORDER SEQUENCE! RETRYING [08:22:56] tnfs_lseek success, new pos=31888, response pos=31888 [08:22:56] ->SIO write 256 bytes [08:22:56] COMPLETE! [08:22:56] [08:22:56] CF: 31 52 80 00 04 [08:22:56] disk sio_process() [08:22:56] ACK! [08:22:56] ATR READ [08:22:56] ->SIO write 256 bytes [08:22:56] COMPLETE! [08:22:56] [08:22:56] CF: 31 52 81 00 05 [08:22:56] disk sio_process() [08:22:56] ACK! [08:22:56] ATR READ [08:22:56] ->SIO write 256 bytes [08:22:56] COMPLETE! [08:22:56] [08:22:56] CF: 31 52 82 00 06 [08:22:56] disk sio_process() [08:22:56] ACK! [08:22:56] ATR READ [08:22:56] ->SIO write 256 bytes [08:22:56] COMPLETE! [08:22:56] Even though the file read essentially comes to a halt and even has the "TNFS OUT OF ORDER SEQUENCE! RETRYING" event while IntelBurnTest is active, this test survived and there was no error from the Atari's point of view. Once I turned off the IntelBurnTest, everything continued as normal. Notice how there are references such as "tnfs_lseek success, new pos=31888, response pos=31888" I am not sure, but this seems to me like the code is adjusting what packet it is asking for because it knows it's out of sequence. This is good. However, in my February 4 example above, there is no reference to this tnfs_lseek adjustment. It's as if in certain scenarios, the tnfs_lseek adjustment is not happening, thus causing the corrupt transfer. Shouldn't every instance of "TNFS OUT OF ORDER SEQUENCE! RETRYING" also be followed up with a "tnfs_lseek success" event? Edited February 8 by chad5200 1 Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 8 Share Posted February 8 23 minutes ago, chad5200 said: Totally understood and I already have a dedicated Raspberry Pi in place to be my TNFS host. The frustrating thing is that this will happen when my PC is doing "nothing" also. It's just that I can help force the situation (for testing purposes) by running a game. But, I am curious to know if this can be corrected in the FujiNet code. It appears that the code KNOWS that it received an "TNFS OUT OF ORDER SEQUENCE! RETRYING" but is sometimes not correcting the packet it should attempt to re-read and instead is just continuing on with the next packet and of course this causes the Atari to receive a corrupted file transfer. Consider this... Here is a new capture of the same GATETEST but this time I am running the IntelBurnTest v.2.54 on Standard Stress Level. I am only sharing the relevant part where I activate the IntelBurnTest. Even though the file read essentially comes to a halt and even has the "TNFS OUT OF ORDER SEQUENCE! RETRYING" event while IntelBurnTest is active, this test survived and there was no error from the Atari's point of view. Once I turned off the IntelBurnTest, everything continued as normal. Notice how there are references such as "tnfs_lseek success, new pos=31888, response pos=31888" I am not sure, but this seems to me like the code is adjusting what packet it is asking for because it knows it's out of sequence. This is good. However, in my February 4 example above, there is no reference to this tnfs_lseek adjustment. It's as if in certain scenarios, the tnfs_lseek adjustment is not happening, thus causing the corrupt transfer. Shouldn't every instance of "TNFS OUT OF ORDER SEQUENCE! RETRYING" also be followed up with a "tnfs_lseek success" event? Yes, I now know that your PC is somewhat broken and that IntelBurnTest completely broke the TNFS server! However the 'tnfs_lseek success' is regularly occuring in my logs too so seems nothing to do with error recovery. If there is any error recovery it will be part of the programming of the TNFS server and Fujinet, so it's guesswork at the moment unless a member here can elaborate? Unfortunately programming is not my strength so I can't tell from the source code that is available from https://github.com/FujiNetWIFI/spectranet. It would also be useful to see a log from the TNFS server itself but I don't know if it is possible to generate one. Does anyone else have a clue? I just had an extrapolated thought re-reading the suggestion that @mozzwald made. Have you tried updating the drivers for your PC from https://www.amd.com/en/support? In particular the Ethernet adapter? Does it show as a Gigabit connection in Windows Network adapter status? Quote Link to comment Share on other sites More sharing options...
mozzwald Posted February 8 Share Posted February 8 1 hour ago, TZJB said: It would also be useful to see a log from the TNFS server itself but I don't know if it is possible to generate one The prebuilt binaries we provide have debugging enabled. If you are running with systemd, you should be able to use journalctl to get the output. Otherwise, you can run tnfsd from the command line and it spits out all the info Quote Link to comment Share on other sites More sharing options...
chad5200 Posted February 8 Author Share Posted February 8 @mozzwald Does it make sense that a "TNFS OUT OF ORDER SEQUENCE! RETRYING" message as seen below would not follow up with a "tnfs_lseek" message? In this debug below, the BASIC program fails to load and the LISTing shows corruption. [10:53:38] [10:53:38] CF: 31 52 7f 00 03 [10:53:38] disk sio_process() [10:53:38] ACK! [10:53:38] ATR READ [10:53:39] Timeout after 1000 milliseconds. Retrying [10:53:41] Timeout after 1000 milliseconds. Retrying [10:53:42] TNFS OUT OF ORDER SEQUENCE! RETRYING [10:53:42] TNFS OUT OF ORDER SEQUENCE! RETRYING [10:53:42] ->SIO write 256 bytes [10:53:42] COMPLETE! [10:53:42] However, here is an example of a "TNFS OUT OF ORDER SEQUENCE! RETRYING" message where the "tnfs_lseek" message does occur afterwards and the BASIC program loads fine: [08:22:53] [08:22:53] CF: 31 52 7f 00 03 [08:22:53] disk sio_process() [08:22:53] ACK! [08:22:53] ATR READ [08:22:53] tnfs_lseek currpos=31888, pos=31888, typ=0 [08:22:54] Timeout after 1000 milliseconds. Retrying [08:22:56] TNFS OUT OF ORDER SEQUENCE! RETRYING [08:22:56] tnfs_lseek success, new pos=31888, response pos=31888 [08:22:56] ->SIO write 256 bytes [08:22:56] COMPLETE! [08:22:56] It seems to me like the logic that attempts to correct an OUT OF ORDER packet is not always happening... thus occasionally corrupting a file read. Quote Link to comment Share on other sites More sharing options...
Kenshi Posted February 8 Share Posted February 8 I tried your program on my setup with my TNFS server (this computer) and it was still running fine after several minutes. I can't think of anything I already have on my computer that would really stress the CPU, but there's no way any computer made in the last 20 years should get so bogged down from a game that it can't send a few kilobytes to another node. It could be something physical with the network that's mostly affecting just your server computer, such as interference or a loose antenna. I'm leaning towards something in the operating system though, such as a bad device driver, a faulty firewall, the computer is running out of memory, etc. Do other programs ever have trouble connecting to internet services? Does the game drop frames? You'd think whatever is causing it, it would affect other programs too. Sorry I can't be of greater assistance, but I'm kind of interested in seeing what the problem is. Quote Link to comment Share on other sites More sharing options...
TZJB Posted February 8 Share Posted February 8 (edited) 2 hours ago, mozzwald said: The prebuilt binaries we provide have debugging enabled. If you are running with systemd, you should be able to use journalctl to get the output. Otherwise, you can run tnfsd from the command line and it spits out all the info Thanks for your suggestion, however you have lost me. We are using the Windows version of TNFSD.EXE and I believe you are referring to the Linux version? I have tried the command line option using Windows Powershell. I can stop the server with taskkill /F /IM tnfsd.exe and start it with start-process O:\tnfsd\tnfsd.exe O:\tnfsroot (I have a lot of drives), a new command window opens but all I get is:- Starting tnfsd version 20.1115.2 using root directory "O:\tnfsroot" Allocating new session for 0x00 Allocated new session for 0x29 This is after accessing the directory, then loading and running the weather client from the Fujinet. No log to speak of. Any ideas? Thanks. Edited February 8 by TZJB Quote Link to comment Share on other sites More sharing options...
mozzwald Posted February 8 Share Posted February 8 10 minutes ago, TZJB said: We are using the Windows version of TNFSD.EXE and I believe you are referring to the Linux version? 10 minutes ago, TZJB said: Starting tnfsd version 20.1115.2 using root directory "O:\tnfsroot" You are using an old version, please use the latest updated yesterday which should have debug output enabled: https://github.com/FujiNetWIFI/spectranet/blob/master/tnfs/tnfsd/bin/tnfsd.exe 22 minutes ago, chad5200 said: Does it make sense that a "TNFS OUT OF ORDER SEQUENCE! RETRYING" message as seen below would not follow up with a "tnfs_lseek" message? Looking at your logs there I see that lseek is not called when there were 2 timeouts in a row. The other had a single timeout and received an out of order packet and continued to lseek. Perhaps it's getting stuck after 1 timeout error Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.