Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Mizar on April 18, 2011, 12:11:34 PM
-
Ever since the summer of '08, AWeb has had problems with grinding to a halt. This never used to happen before that. I don't believe I made any changes on my system then- it must've been something that changed web-wide. My ISP was also upgrading some equipment/protocols with their servers at this time. I was using AWeb 3.4 APL then. I use Genesis for the TCP/IP stack.
I since have upgraded to AWeb 3.5.09. There was only slight improvement with this problem after upgrading. I currently have narrowed it down to the amount of time the browser is open is what seems to determine when it will grind to a halt (as opposed to anything to do with the TCP/IP stack or the whole A1200), but it greatly varies on how long this takes. Sometimes exiting AWeb and restarting gets it going again for a little while, but it seems to take rebooting the Amiga to really get it going again usually. I've also noticed that if I am telnetting at the same time, that is the only thing that allows AWeb to remain capable of transfers without restarting it or rebooting.
Does anyone else have this problem with AWeb or know what is causing it?
BTW, IBrowse 2.3 became completely unusable at (I believe) the same point in time, and for the same reason. Except it is pretty much dead in the water all the time. (I'm about to upgrade it to 2.4- haven't tried it yet.)
-
If it happens on both browsers then it might be an issue with the internet signal.
Have you tried viewing files that are stored locally on the harddrive in A-web to see if you get the same problem
-
If it happens on both browsers then it might be an issue with the internet signal.
Have you tried viewing files that are stored locally on the harddrive in A-web to see if you get the same problem
Yes, there's never a problem when viewing local files. I've always figured it had to be a problem with the internet. I switched ISPs from the one I had when the problem started, but the same thing happens. It's as if it's some kind of new protocol going on with the web, or with all the ISP's DNS, since that point in time (around Aug. '08).
-
@Mizar
I have what sounds like a similar or maybe the same problem. But note that I am on dial-up still and I thought that this problem was specific to my bad phone line conditions, etc.
Any individual program stops communicating after some time. To keep AWeb working, I leave a page open with small images on it (e.g. a page like this in a forum) and ask to reload a small image when the xfer stops. After a while, I need to start a xfer several times to keep things going.
I haven't tried on my A1200, but this happens with my Amithlon box running Genesis and is also happens on my OS4 box.
A "solution" that works for my OS4 box is to open a command line shell and type "ping http://www.google.com interval 5" (for example) for the whole time I'm online. Xfers then only stall for five seconds or so, not forever.
And yes, the same problem afflicts my Linux box. It really seems to be something caused by bad line conditions or something at my ISP.
-
There are still people on dial-up ouch
I get annoyed that I am in one of the top ten black spots for broadband in the uk being 3 and half miles from the exchange and can only get 2mb
-
Might be a port issue. Maybe someone could advise if they know what ports the Amiga would use to access the internet
-
same as any computer , prime port is 80
-
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.
AWeb 3.4 works just fine in every setup of mine, so I'm sticking with it atm.
-
@Mizar
I have what sounds like a similar or maybe the same problem. But note that I am on dial-up still and I thought that this problem was specific to my bad phone line conditions, etc.
Any individual program stops communicating after some time. To keep AWeb working, I leave a page open with small images on it (e.g. a page like this in a forum) and ask to reload a small image when the xfer stops. After a while, I need to start a xfer several times to keep things going.
I haven't tried on my A1200, but this happens with my Amithlon box running Genesis and is also happens on my OS4 box.
For your Amithlon box, in GenesisPrefs --> Options --> Advanced, make sure TCP buffer size is exactly 8192 for send and receive. Any larger than that and you could experience "TCP exponential backoff" resulting in longer and longer pauses.
And yes, the same problem afflicts my Linux box. It really seems to be something caused by bad line conditions or something at my ISP.
You could try editing /etc/sysctl.conf and adding these two lines:
net.ipv4.tcp_rmem = 4096 8192 32768
net.ipv4.tcp_wmem = 4096 8192 32768
-
@Mizar
I have what sounds like a similar or maybe the same problem. But note that I am on dial-up still and I thought that this problem was specific to my bad phone line conditions, etc.
Any individual program stops communicating after some time. To keep AWeb working, I leave a page open with small images on it (e.g. a page like this in a forum) and ask to reload a small image when the xfer stops. After a while, I need to start a xfer several times to keep things going.
I haven't tried on my A1200, but this happens with my Amithlon box running Genesis and is also happens on my OS4 box.
A "solution" that works for my OS4 box is to open a command line shell and type "ping http://www.google.com interval 5" (for example) for the whole time I'm online. Xfers then only stall for five seconds or so, not forever.
And yes, the same problem afflicts my Linux box. It really seems to be something caused by bad line conditions or something at my ISP.
I am still on dial-up too. That was what I fogot to mention! I don't think it's bad phone lines. Like I said, this never used to happen to me, it just started up all the sudden in '08 at the same time as my ISP was updating their stuff (to what other ISPs are using). And if it really was bad connectivity through the phone lines, your strategy of reloading small images or using continuous pings would not help because data would still not be able to get through, in any case. I recall getting info in the past that suggested it is being caused by the prevalence of broadband, and therefore the dial-up accommodation is being compromised by the protocols that are so broadband oriented. So it is the second cause you mention- something at your ISP (and all ISPs anymore).
What do you mean by "any individual program" stops communicating after some time? Is it just AWeb (or other browsers) having transfer problems, or are you talking about other internet clients as well, ie. telnet, e-mail, etc.?
Most interesting that this transfer problem is occuring on Amithlon, OS4, and even Linux. The common factor here is the "dial-up" networking, I believe. Though this does not happen with Win browsers, even old ones. I had been using NetScape 4.74 on Win95 on dial-up also, and there were no transfer delay problems (just the usual dial-up slowness :-). Seems it's only quality OSs' browsers that are affected by the dial-up grinding-to-a-halt problem. :-(
My strategy of using telnet connections to keep AWeb's transfers going was rather a hassle. And it still is when repeatedly restarting AWeb or rebooting. I like your strategy better, especially of using continuous pings. I had thought of that and tried it some, but didn't keep it going for an extended time, so I didn't realize it worked! (on an A1200)
BTW, I'm not planning on staying with dial-up much longer, as there's still PCMCIA ethernet cards available :-). And they're not too expensive either. This further adds to what I have been wondering about, if switching to broadband would cure these darn web transfer problems. It's sounding like it :-). And even if dial-up weren't forever more plagued with such problems, broadband would still be so much faster and nicer.
-
I get annoyed that I am in one of the top ten black spots for broadband in the uk being 3 and half miles from the exchange and can only get 2mb
Thats double what I can get and mine is not even reliable. I've been holding out switching to virgin cable but I think I'll have to.
-
I am still on dial-up too. That was what I fogot to mention! I don't think it's bad phone lines. Like I said, this never used to happen to me, it just started up all the sudden in '08 at the same time as my ISP was updating their stuff (to what other ISPs are using).
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.
-
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.
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.
AWeb 3.4 works just fine in every setup of mine, so I'm sticking with it atm.
mfilos:
I have an FPU, but that's never prevented the halting issues. I used AWeb 3.4 earlier, and it had even more halting problems. At least AWeb 3.5.09 can keep going for around 2-4 hours before grinding to a halt often, whereas 3.4 would halt right from the start IIRC. You didn't mention if you are using dial up?
What do you mean by "adding +FPU" to your config?
-
@Mizar
What do you mean by "adding +FPU" to your config?
I mean adding FPU as an option under WinUAE. If FPU is added, AWeb 3.5 doesn't halt upon loading a webpage.
-
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.
-
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
-
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.
-
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.
-
>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.
-
Thanks a lot Minuous mate!
I thought for some time that I was doing something wrong :)
-
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.
-
I have all the copies from AWeb 3.4 and 3.5 including the ones for 68000.
(http://oi53.tinypic.com/if5pxc.jpg)
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)
-
>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).
-
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!
-
That would be great Minuous mate! I'm looking forward for it as well \o/
-
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.