On Sat, 13 Jan 2001, David Woolley wrote:
> I'm beginning to discover that Miami can be surprisingly unstable. From time
> to time, it will lock up. As I run Miami iconified, the first I know of
> this is when web pages stop loading. Then trying to bring up Miami's
> interface causes a crash.
How much RAM is free at the time (both FAST and CHIP)? Some browsers
cache images in CHIP RAM, and can eat it all up fairly easily.
> After the reboot, Miami can't get back online- even if I have "Quick
> Reconnect: File" set. The only way to get offline from there is to switch
> the modem off. Trying to click on "Cancel" results in another lock-up.
That's very likely a driver bug.
On Sat, 13 Jan 2001, Colin Wenzel wrote:
> On 13-Jan-01, David Woolley wrote:
> > On 13-Jan-01, Julian Aronowitz wrote:
> >> Second, if all of your settings are correct, for your ISP and
> >> your modem and your telephone service (tone vs. rotary/pulse),
> >> then, the culprit can still be the phone company or the ISP's
> >> servers.
>
> Watch out for VJC header compression, some don't like that on.
True, but most either support it or refuse it gracefully. In any case, a
bug in that area would prevent getting connected at all.
> > Speed: 115200 Use CD
>
> Use 57600, 115200 is seriously pushing it using the amiga serial port,
> I get no extra advantage over 57600 that is measurable,
> plus, it gives you a nice safety margin...
Yes, especially when using the native display. Even 57600 can be
problematic with a maximum-bandwidth display.
> PS: Don't try using 76800, it's not a valid serial speed your modem
> understands. I think it's for MIDI or something...
No, MIDI is 31250. 76800 is a perfectly valid speed, but only some modems
support it.
> > Multicasts: disabled MTU: 552
> MTU is always 1500 here......
MTUs that large aren't very desirable on serial links, especially when VJC
is available. Large packets on slow lines worsen the impact of bulk
transfers on interactive response.
> > PPP page:
> > Allow MS-CHAP ticked Accm: a0000
With most ISPs you can set the ACCM to all 0 for slightly better
performance, unless you're using XON/XOFF flow control.
> MS-CHAP causes problems here, turn it off"
Unless of course the ISP needs it, such as one using NT-RAS.
> > Same as in dialer ticked
> > VJC ticked
> Loose the VJC....
Only if it doesn't work otherwise, and this clearly isn't that type of
problem.
On Sat, 13 Jan 2001, kevin orme wrote:
> I would also maybe try a DiskSalv/repair or Quarterback repair on your
> partition where Miami is installed (dh0: or otherwise). My A3000's
> Miami locks up from time to time, but I don't really think it's Miami, I
> think it's the disk.
Unlikely. And disk repair tools only deal with problems in the file
structure. Porblems with the *content* of the files can neither be
detected nor corrected by repair tools.
On Sun, 14 Jan 2001, Tim Seifert wrote:
> By: Colin Wenzel <[EMAIL PROTECTED]>
> On: Sunday, January 14, 2001, 4:56:51 AM
>
> > 1: Yes, set quick reconnect to "disabled".
> > And yes, it still works, it just renegotiates a new DNS
> > when it reconnects.
>
> Only if your ISP supports that. Not all do. Some will fail to give the
> information you require from the ISP, other ISPs will hang up immediately.
>
> If your ISP is usable with permanent DNS settings in your configuration,
> doing so should help with reconnections. Again, this doesn't work with
> all ISPs, because some ISPs answer each call with different equipment, and
> you may not always use the same DNS server.
It's not just a DNS issue - "reconnecting" essentially means violating the
PPP state machine and hoping that the server will take it in stride.
Quick Reconnect is a kludge that tries to remember enough to "continue"
the PPP session after the crash, but it doesn't always work either, and
meanwhile adds to the things that can be screwed up across reboots.
Unless you have a really good reason to keep the connection across a
crash (per-call phone charges, mostly busy dialups, etc.), I recommend
avoiding that altogether. Starting with everything fresh minimizes the
chance of inheriting "poison" from before.
> > 2: Add "&D0" to your init string... (no quotes)
If you don't need to preserve calls across reboots, then &D2 is better
here, since it gives you a much more reliable means of hanging up.
> > 3: Tick "Use CD" in the 'Interface' section..
>
> These apply no matter which way you're trying to do a re-connect, if you
> don't want the MODEM to hang up, when your Amiga serial port goes off.
"Use CD" is almost always a good idea, since aside from its effect on
reconnection, it also allows Miami(Dx) to recognize loss of carrier as a
disconnect. It's too bad these two effects aren't controllable
separately. The main reason to disable "Use CD" is when using an
incomplete cable or a modem that can't be configured for correct CD
behavior.
> However, the message says the person "can't" hang up their MODEM without
> switching it off, so they've probably already got similar &D settings.
> But, not having the "use CD" selected sounds likely, as the reason for not
> being able to do a re-connect. Both are essential, for reconnecting.
True.
> I've have had Miami get stuck for ages, with a similar situation, but I
> can't recall a total lock up.
A typical problem is where Miami(Dx) is trying to get the modem's
attention with "+++" or whatever and the modem isn't recognizing it.
On Sun, 14 Jan 2001, Tim Seifert wrote:
> By: David Woolley <[EMAIL PROTECTED]>
> On: Sunday, January 14, 2001, 9:50:00 AM
>
> > I've also done the changes you mentioned in the other post. I'd like to
> > stick to 8n1, I use a DBLPAL mode, and even Miami's serial device is
> > unuseable slow with this screenmode.
>
> There used to be dire warnings about using 8n1. Whether that still
> applies, I don't know, but many of those speed-up hacks do so by not doing
> proper error checking, etc. (it's "quicker" not to do everything a serial
> port is meant to).
AFAIK 8n1.device is still flaky. The issue isn't so much lack of error
checks as just plain bad code that causes crashes and hangs.
I used to use artser before the built-in serial driver appeared. There's
also v34serial.device, which seems to be somewhat faster than serial or
artser, but less buggy than 8n1. I haven't used it enough to be sure of
its long-term stability, though.
> Chip RAM VGA screen modes do mean that there is less time available for
> the CPU to do other things that you want to be doing. I found web
> browsing to be abominable, because to run the browser with enough colours
> to see a page at a reasonable level (and I was only using 64 colours),
> meant it kept crapping out during file transfers. That was on an AGA
> A1200, with a 33MHz 68030 with MMU, 33 MHz 68882 FPU, and 16 megs of RAM,
> by the way.
Yes, this has almost nothing to do with the CPU speed or the amount of
RAM.
On Sat, 13 Jan 2001, Paul Braithwaite wrote:
>
> Have you had a look at your MUI settings? Have you loaded any "new" MUI
> libs lately, or have you installed any software that might have?
Another good thing to check. There have been "improved" versions of some
MUI classes that are buggy.
On 14 Jan 2001, Trevor Daley wrote:
> On 14-Jan-01 08:20:00 *David Woolley* wrote about [Miami] Re: Miami
> Instability, so I though I would say...
>
> DW> I've also done the changes you mentioned in the other post. I'd
> DW> like to stick to 8n1, I use a DBLPAL mode, and even Miami's
> DW> serial device is unuseable slow with this screenmode.
>
> Ahhh! There's your problem, this was explained to me many years ago by
> Holger.
>
> The problem is that your Ami's internal serial port uses the CPU for
> buffering (or something like that) your serial port. The AGA chipset
> also uses the CPU for something, this slows down the serial port
> considerably.
Not exactly. There are two problems:
1) All accesses to Amiga custom chips, including the native serial port,
use the same bus as CHIP RAM, and have to contend with CHIP RAM DMA from
things like the display. With a maximum-bandwidth native display active,
all other accesses are locked out completely during the active display
time, leaving things like serial-port register accesses begging for scraps
of time during the horizontal retrace (also vertical, but those don't
happen often enough).
2) The native serial port has only minimal buffering, thus requiring it to
be serviced within a single character time to avoid losing data.
> Two ways to fix this are...
>
> 1) Buy one of the many serial port repacements.
> 2) Tower your Ami and buy a graphics card.
>
> A simple fix for the time been is to reduce the screen depth, anything
> over 64 colours can cause interference to the builtin serial port.
Or reduce the baud rate.
The bottom line here is that attempting to get around the limitations of
the serial port by using a buggy serial driver (8n1.device) is not
conducive to system reliability. If Miami's built-in driver doesn't work
reliably, then fix the baud rate and/or screenmode so that it does.
On Mon, 15 Jan 2001, Julian Aronowitz wrote:
> FWIW, I have been using artser.device and have had no problems
> with Miami. That is available on Aminet. I believe it is found
> as artser.lha.
>
> When you do use artser.device, or any replacement
> serial.device, remember, if you wish to use something with uses
> the Amiga's own serial.device, you *will* have to reboot. There
> appears to be no way to substitute one type for another, on the
> fly.
This depends on the particular driver, but in any case at most an "avail
flush" is needed to get the former driver to let go of the port. A reboot
isn't needed.
> If you wish to speed up screen mode, then reduce the number
> of colors set for your Amiga. Sometimes, that can make all the
> difference in the world.
Yes, stick to no more than 64 on AGA, or 8 on ECS/OCS.
Fred Wright
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
