AWeb 3.5.09 grinds to a halt- why?

[Mizar]

Well, what is your TCP buffer size?  If it's already 8192, you still might be able to minimize your problem by using an MTU of 576, limiting simultaneous browser connections to 2 or 3, etc.

In Genesis the MTU is 576, in Miami it's 552.  Those and the TCP buffer values are the defaults.  However, I reduced AWeb's max network connections to 3, from 12.  That seems to be helping.  It seems to take longer to grind to a halt sometimes, and when it seems to be halting it sometimes starts moving again somewhat after a bit.  Other times I can keep it going pretty much indefinitely.

And then there's times like today, where it grinds to a halt after a short time no matter what.  I had to resort to telnetting again as the only thing that will keep it going.

I'm playing with some other TCP settings that have the potential to optimize browser speeds.

[jj]

My GenesisPrefs TCP buffer send/receive size is 8192, and has been.

JJ:

Not only am I still using dial-up, but mine only goes 28.8 k to 31.2 kbps.  I guess there aren't fiber optic lines around here.  You get 2MB per sec.?  That sounds pretty good... would be for a PCMCIA ethernet card anyway.

Thats through ASDL and is very slow, should be able to get up to 8mb.  Not got fiber otherwise would be on 50mb or 100mb

[Mark]

In Genesis the MTU is 576, in Miami it's 552.  Those and the TCP buffer values are the defaults.  However, I reduced AWeb's max network connections to 3, from 12.  That seems to be helping.  It seems to take longer to grind to a halt sometimes, and when it seems to be halting it sometimes starts moving again somewhat after a bit.  Other times I can keep it going pretty much indefinitely.

And then there's times like today, where it grinds to a halt after a short time no matter what.  I had to resort to telnetting again as the only thing that will keep it going.

I'm playing with some other TCP settings that have the potential to optimize browser speeds.

From what you've written, it sounds like you need to reduce latency, not increase overall speed.  For example, increasing MTU to 1500 will reduce overhead and increase transfer speed.  It also increases latency and makes stalls more likely on slow connections.  Reducing MTU to 296 does the opposite.

If you're doing wild experiments with settings, I suggest you write down what was changed, why, and what the original settings were.  I say that because some undesirable side effects may not become apparent for quite some time.  Also, if your problem is mainly with the A1200, double check your serial device settings in Genesis.  Maybe you're using some buggy serial.device replacement or your baud rate is a little too high for the A1200.  Flow control should be RTS/CTS if at all possible.

Some 34k and 56k modems can be flashed with upgraded firmware that improves performance -- you might check with your modem's manufacturer.

[Mizar]

From what you've written, it sounds like you need to reduce latency, not increase overall speed.  For example, increasing MTU to 1500 will reduce overhead and increase transfer speed.  It also increases latency and makes stalls more likely on slow connections.  Reducing MTU to 296 does the opposite.

If you're doing wild experiments with settings, I suggest you write down what was changed, why, and what the original settings were.  I say that because some undesirable side effects may not become apparent for quite some time.  Also, if your problem is mainly with the A1200, double check your serial device settings in Genesis.  Maybe you're using some buggy serial.device replacement or your baud rate is a little too high for the A1200.  Flow control should be RTS/CTS if at all possible.

Some 34k and 56k modems can be flashed with upgraded firmware that improves performance -- you might check with your modem's manufacturer.

I shall have to try a lower MTU then, even though 296 is normally for 19.2k and under modems.

I'm not doing wild experiments.  I'm only changing one thing at a time, so I know what is affecting what.  And I'm not screwing with advanced settings, just turning various TCP protocols and settings on and off in Miami.  So far, I established I didn't need DHCP or Verify DNS turned on, which only slow my internet log on way down.  Plus, Verify DNS was preventlng me from being able to use my ISP's DNS, because apparently they no longer respond to verify queries (Genesis wasn't using these).  Also, I tried using T/TCP (the one I mentioned that could potentially speed up browsing)... so far I think it only interfered.  Probably my ISP's DNS support it, but I don't know about AWeb.  I tried to look it up but AWeb's internal search function is broken.

Yes, my problem is only with the A1200.  However, another member had said he was having these same problems with AWeb with OS4, WinUAE, and even on a Linux box.  I've been using these same settings for a long time, and they had always worked fine.  It wasn't until things started changing on the net that I started having problems, though I was not playing with settings at all at that time (if it ain't broke, don't fix it- but now it is broke).  My serial settings are 115200 bps, RTS/CTS, 8N1, and using squirrelserial.device, which I've never known or heard about being at all buggy.  (Back when I had tried rates higher than 115200, that didn't seem to work well.)

My modem is 33.6k.  Interesting idea, I'll have to see if there's a firmware update possibility.

[Minuous]

>AWeb 3.5 (which was included in BB3) halts on my A600 with ACA630 (and also in my clone test environment under WinUAE). If I test it under WinUAE (with same config as my A600) but with adding +FPU... AWeb 3.5 runs just fine without halting issues! I guess it requires an FPU to work (unless there is a way to disable that).

Confirmed. It seems to be compiled with GCC's -m68020-60, which is documented as: "Generate output for a 68060, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060." So in other words, that build does require an FPU.
  It would have been better to compile it with -m68020 or (if 68000 compatibility is required) with -m68000.

[mfilos]

Thanks a lot Minuous mate!
I thought for some time that I was doing something wrong

[matthey]

Confirmed. It seems to be compiled with GCC's -m68020-60, which is documented as: "Generate output for a 68060, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060." So in other words, that build does require an FPU.

Not necessarily. If no floating point data is used then, most likely, no FPU code will be generated. I don't know how much fp is used but I suspect not much. Generating only 1 executable is certainly a compromise and not a good one for those without a FPU. Using the IEEE math libraries would be better in this case.

  It would have been better to compile it with -m68020 or (if 68000 compatibility is required) with -m68000.

There was a 68000 compiled version of AWeb on the sun site before it was deleted. It should work without FPU on a 68020+ although not optimal. Maybe someone has a copy.

[mfilos]

I have all the copies from AWeb 3.4 and 3.5 including the ones for 68000.



All 3.4 versions as I said work without issues. The 3.5 versions work but once you browse any website with pictures it halts asking for Suspend/Reboot.

The 3.5 68000 version works just fine without halts!

I guess sticking with 3.4 is the best option for now (unless you want the 3.5 68k version)

[Minuous]

>Not necessarily. If no floating point data is used then, most likely, no FPU code will be generated. I don't know how much fp is used but I suspect not much.

Actually there's quite a bit. The internal PNG support as well as the PNG plugin both use the FPU. Also a lot of websites such as http://www.google.com and http://www.yahoo.com crash it if there is no FPU, even with image loading turned off.

I'm working on a backport of AWeb 3.5.10 to SAS/C. If this is successful, I will build it for 68EC020 (and for other CPUs if requested).

[Gulliver]

I'm working on a backport of AWeb 3.5.10 to SAS/C. If this is successful, I will build it for 68EC020 (and for other CPUs if requested).

I am looking forward for it!
I hope you succeed!

[mfilos]

That would be great Minuous mate! I'm looking forward for it as well \o/

[Mizar]

All 3.4 versions as I said work without issues. The 3.5 versions work but once you browse any website with pictures it halts asking for Suspend/Reboot.

The 3.5 68000 version works just fine without halts!

I guess sticking with 3.4 is the best option for now (unless you want the 3.5 68k version)

This is a separate phenomenon being described using AWeb without an FPU.  The "halting" issue I was describing was not a hang/crash of AWeb, only that it stops loading the page/images part way.  I had the same transfer problem with 3.4 as with 3.5, but had a little more luck with things continuing to load until it started grinding to a halt with 3.5.09.

I also tried reducing the MTU to 296, and that didn't help the transfer problem.  In fact, I found the only way to reliably keep transfers going was what I originally had been doing, to telnet at the same time.  No other method suggested produced significant improvement consistently.  I'm still thinking the problem is tied to the lack of ISP support for dial-up, though I haven't had time to experiment further with this yet.