dac@prolix.ccadfa.oz.au (Andrew Clayton) (12/19/90)
Since this article psuedo answers a previously asked
question/problem, here is the problem definition first:
I have an A2500/30 with 9Mb memory, 115Mb HD, and V32 modem,
running AmigaDos 1.3.2, with AmigaUUCP 1.06D, talking to my
newsite ccadfa (Canberra, Australia).
When I attempted to call my site with UUCICO at 9600, I
found that my sessions were being prematurely terminated, usually
after the reciept of one or two bundles of compacted news (50K
per bundle). On switching to 2400bps operation I found that
everything worked fine, but was tediously slow. My site only
agreed to provide my partial USEnet feed on the basis that I
would be connecting at 9600bps, and not taking up too much of
their modem time - my site supplies many users, and only
has two modem lines.
After purchasing an ASDG dual serial port board to attempt to
solve my problems with UUCP (Tuesday, +10gmt), I found that I
still had the same problems. Note that I have NO problem with
Zmodem transfers (950-1100cps transfer rates) in previous use of
the V32 modem.
The lastest attempt to fix the problem worked:
I placed the SPOOL: directory in RAM:!
Of course, this means that any power failure will trash my news,
but I can live with that threat. Power failures are fairly rare,
and almost always avoidable at home.
Now that UUCICO isn't writing to my HD anymore, the problem of it
hiccoughing, and assuming that my news site has stopped
transmission, has dissapeared. The delay between writing out the
50K packets to disk and looking for more input was apparently too
much.
My HD is a Rodime 44Mb ST506 interfaced one, running off a CBM 2090a
disk controller. Diskperf reports 100-250K/sec transfer rates,
depending on how big a buffer is used.
I'm at a loss to explain why a 100Kbyte/sec device cannot keep up
with a 1Kbyte/sec device. Explanations aren't really required. :-)
Solutions (other than mine : assigning UUSPOOL to RAM:Spool) are
welcome though.
p.s. I continue to be amazed at the wealth of information in this
network, at the same time being dismayed at the bickering and
reiteration that goes on in technical areas. Long live alt.flame.
Dac
_l _ _ Andrew Clayton. I post . ccadfa.cc.adfa.oz.au!Uprolix!dac
(_](_l(_ Canberra. Australia. . . I am.
Note: I cannot send or recieve MAIL to sites outside of Australia. Sorry.johns@pro-graphics.cts.com (John Silvia) (12/24/90)
In-Reply-To: message from dac@prolix.ccadfa.oz.au
The "hiccup" that you are getting is inherant of most of the DMA disk
controllers that are out there. If you had updated your hard disk controller
to a fully interrupt driven system, then the machine would not slow down
during these pauses, and there would be no problem.
One example of this that I have seen is when people use things like Broadcast
Titler 2.0, on a system with a DMA controller, and they try to make a
something large do a horizontal scroll. Sometimes the "hiccup" kicks in, and
the image jumps.
On my system, A2500/30, 1 meg chip, 2 megs 32bit, GVP Faastrom Series II
controller running under dos 2.0, I have no problems with this "hiccup" but a
similar system which runs with a different DMA type controller will - and has.
-- John Silvia
Pro-Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!"
Internet: johns@pro-graphics.cts.com
UUCP: crash!pro-graphics!johns
ARPA: crash!pro-graphics!johns@nosc.millron (12/24/90)
In article <6502@crash.cts.com>, John Silvia writes: > In-Reply-To: message from dac@prolix.ccadfa.oz.au > > The "hiccup" that you are getting is inherant of most of the DMA disk ^^^^ ^^^ some NON-DMA > controllers that are out there. If you had updated your hard disk controller > to a fully interrupt driven system, then the machine would not slow down > during these pauses, and there would be no problem. All the controllers use interupts. It's just some of them have driver software that leave all the interupts disabled for excessive periods of time. It is most common in controllers that do NOT use DMA and have the CPU copy the DATA into ram. The PP&S Vault, Cltd and Kronos controllers all have this problem. > One example of this that I have seen is when people use things like Broadcast > Titler 2.0, on a system with a DMA controller, and they try to make a > something large do a horizontal scroll. Sometimes the "hiccup" kicks in, and > the image jumps. The problem is the driver software not the controller. The GVP controllers have good driver software. > On my system, A2500/30, 1 meg chip, 2 megs 32bit, GVP Faastrom Series II > controller running under dos 2.0, I have no problems with this "hiccup" but a > similar system which runs with a different DMA type controller will - and has. I use a DMA controller and play games like Wings off of it and there are NO interuptions in sound/animation during drive accesses. ----------------------------------------------------------------------------- | Dwight Hubbard, |-Kaneohe, Hawaii | | USENET: lron@easy.hiam or uunet!easy!lron |-GT-Power: 029/004 | -----------------------------------------------------------------------------
dac@prolix.ccadfa.oz.au (Andrew Clayton) (12/24/90)
In article <6502@crash.cts.com>, John Silvia writes: > The "hiccup" that you are getting is inherant of most of the DMA disk > controllers that are out there. So, when I put a 230Mb SCSI on my GVP A3001 card, replacing one of my two ST506 (2090a) hard drives, the problem will be history? Well, I can hope. :-) > On my system, A2500/30, 1 meg chip, 2 megs 32bit, GVP Faastrom Series II > controller running under dos 2.0, I have no problems with this "hiccup" but a > similar system which runs with a different DMA type controller will - and has. Disconcertinly, I lost information today even when using UUCICO with UUSpool: assigned to RAM:Spool. Running PerfMon at the same time, I found that with just PerfMon, a CLI, Workbench in the background, I was using no measurable CPU, when I start UUCICO, (talking 9600 via an ASDG dual serial board) I see an immediate 75% usage of the CPU. (30Mhz 68030/68882). This can't be right! :-(. My session bombed out (twice), and I had to go back to 2400. Perhaps it was line noise, who knows, but it is very frustrating when the threat of network excommunication lying over me if I don't use 9600! > -- John Silvia -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am. -------- I cannot send or recieve mail to or from sites outside of Australia.
lron (12/25/90)
In article <186a6051.ARN00669@prolix.ccadfa.oz.au>, Andrew Clayton writes: > In article <6502@crash.cts.com>, John Silvia writes: [previous stuff deleted] > Disconcertinly, I lost information today even when using UUCICO > with UUSpool: assigned to RAM:Spool. Running PerfMon at the same > time, I found that with just PerfMon, a CLI, Workbench in the > background, I was using no measurable CPU, when I start UUCICO, > (talking 9600 via an ASDG dual serial board) I see an immediate > 75% usage of the CPU. (30Mhz 68030/68882). > > This can't be right! :-(. My session bombed out (twice), and I > had to go back to 2400. Perhaps it was line noise, who knows, but > it is very frustrating when the threat of network excommunication > lying over me if I don't use 9600! At 9600 with a protocol as inefficent as UUCP-G 75% cpu wouldn't suprise me to much. The data is after all coming in 1 byte at a time. I just wanted to say it sounds like your handshaking is not set up right somewhere. Make sure your modem is set for hardware flow control( CTS and will only recieve data when RTS is high) also if you have the modems using MNP or V.42/V.42bis make sure that the modem is running with the DTE/DCE rate fixed at the DTE(computer) rate. This has to be set up properly on BOTH ends in order to work correctly. The other thing is if your drive is one of those drives that causes the mouse pointer to jump during drive accesses, don't do any disk I/O as it will cause real problems for the serial port. ----------------------------------------------------------------------------- | Dwight Hubbard, |-Kaneohe, Hawaii | | USENET: lron@easy.hiam or uunet!easy!lron |-GT-Power: 029/004 | -----------------------------------------------------------------------------
dac@prolix.ccadfa.oz.au (Andrew Clayton) (12/26/90)
In article <186ab686.ARN08a7@easy.hiam>, (Dwight Hubbard) writes: > In article <186a6051.ARN00669@prolix.ccadfa.oz.au>, Andrew Clayton writes: > > > Disconcertinly, I lost information today even when using UUCICO > > with UUSpool: assigned to RAM:Spool. Running PerfMon at the same > > time, I found that with just PerfMon, a CLI, Workbench in the > > background, I was using no measurable CPU, when I start UUCICO, > > (talking 9600 via an ASDG dual serial board) I see an immediate > > 75% usage of the CPU. (30Mhz 68030/68882). > > > > This can't be right! :-(. My session bombed out (twice), and I > > had to go back to 2400. Perhaps it was line noise, who knows, but > > it is very frustrating when the threat of network excommunication > > lying over me if I don't use 9600! > At 9600 with a protocol as inefficent as UUCP-G 75% cpu wouldn't > suprise me to much.The data is after all coming in 1 byte at > a time. So I gathered. > I just wanted to say it sounds like your handshaking is > not set up right somewhere. Make sure your modem is set for > hardware flow control( CTS and will only recieve data when RTS is > high) also if you have the modems using MNP or V.42/V.42bis make > sure that the modem is running with the DTE/DCE rate fixed at > the DTE(computer) rate. I tried fixed 19.2K (I only have V.32), and it didn't solve anything. The site I feed off has other sites feeding off it, with no complaints. I am not sure about the flow control situation, and I'll try some combinations of DTR and CTS/RTS, Thanks for the suggestion. > ends in order to work correctly. The other thing is if your > drive is one of those drives that causes the mouse pointer > to jump during drive accesses, don't do any disk I/O as it will > cause real problems for the serial port. My mouse pointer doesn't 'go jerky' due to HD transfers, only when some spastic program (like Online! V2) decides to forbid multitasking! :-( [No, I'm not using Online! to communicate with a UUCP site :-), it's just an example.] On the seemingly silly suggestion that this 'problem' with UUCP was only recently being seen with 68030 owners, I reverted to 68000 (7.14Mhz) mode, and proceeded to get my mail to RAM:, at 9600, without a hitch. The unfortunate side effect is that RNEWS/Uuxqt are real dogs in 68000 mode, and automatically start up when UUCICO finish. :-(. I'll try it on HD with 68000 mode with tommorrows mail session. Apologies to those of you getting tired of this thread. > | Dwight Hubbard, |-Kaneohe, Hawaii | -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am. -------- I cannot send or recieve mail to or from sites outside of Australia.
jason@cbmami.UUCP (Jason Goldberg) (12/26/90)
In article <186cb910.ARN00704@prolix.ccadfa.oz.au>, Andrew Clayton writes: (Sorry to post but he can't send/recieve mail...) > > On the seemingly silly suggestion that this 'problem' with UUCP > was only recently being seen with 68030 owners, I reverted to > 68000 (7.14Mhz) mode, and proceeded to get my mail to RAM:, at > 9600, without a hitch. The unfortunate side effect is that > RNEWS/Uuxqt are real dogs in 68000 mode, and automatically start > up when UUCICO finish. :-(. > I can't believe you thought my suggestion was silly ;-) Actually I mentioned that all of us reporting the problem had 68030's, only because people kept sending me mail saying maybe our CPU's were too slow. I never thought that, the 68030 could be the cause. So the next question is, do you run SetCPU? What version and options do you use? It could be that we both have some type of cache set up that UUCP doesn't like. I have sent a copy of my -x9 output to Matt Dillon in the hopes that he can shed some light on this for us. Incedently, I have a 2091 controller with SCSI harddrives and have the same problem of no 9600 V.32 UUCP transfers that you have. I can transfer to the same site/modem via 9600 Z-Modem or 2400 via UUCP. So I don't think your problem is related to the HardDrive, I have also tried putting the uuspool: in ram to no avail. I am thinking of getting UUCPPlus and seeing if that works, also I have heard rumors that UUCP1.07 is due out in January. GoodLuck, -Jason- --------------------------------------------------------------------------- Jason Goldberg UUCP: ucsd!serene!cbmami!jason Del Mar, CA
dac@prolix.ccadfa.oz.au (Andrew Clayton) (12/27/90)
In article <186c4a0d.ARN0cc6@cbmami.UUCP>, Jason Goldberg writes: > In article <186cb910.ARN00704@prolix.ccadfa.oz.au>, Andrew Clayton writes: > (Sorry to post but he can't send/recieve mail...) > > > > On the seemingly silly suggestion that this 'problem' with UUCP > > was only recently being seen with 68030 owners, I reverted to > > 68000 (7.14Mhz) mode, and proceeded to get my mail to RAM:, at > > 9600, without a hitch. > I can't believe you thought my suggestion was silly ;-) Cruelty is my business. :^) > Actually I mentioned that all of us reporting the problem had > 68030's, only because people kept sending me mail saying maybe > our CPU's were too slow. I never thought that, the 68030 could > be the cause. I too was of the opinion that perhaps the 68000 could have been a tad slow for 9600, but I consider that there is no way that a 68030 at 1100% plain Jane Amy speeds can 'lose' data from the serial port. > So the next question is, do you run SetCPU? What version > and options do you use? It could be that we both have some type > of cache set up that UUCP doesn't like. Great minds think alike. I had a brainstorm whilst waiting for 7.00pm (+10GMT) to come around so that I could pick up my mail. I thought 'Hey, maybe the CACHE and BURST modes on my 68030 are doing something funny with uucico?' So I dutifully reverted my mail procedure to point the spool to HD, and to call SetCPU to turn off the Cache and Burst modes, and then call uucico. Worked like a charm! Perfmon running at the same time [who said multitasking wasn't useful] showed the the CPU resource was *almost* flatlined, prolly around 5-10% free CPU. There were a few 'sequence' errors in the transmission, but I got my mail packets without uucico crapping out, so I'm convinced that we have the solution to our problem. I hope that Matt gets the information [I would mail him, but I can't use mail :-(] and places a warning in his release of 1.07D, stating that CACHE and BURST mode *could* affect uucico operation on Amiga's that use 68030's. > Incedently, I have a 2091 controller with SCSI harddrives and have the > same problem of no 9600 V.32 UUCP transfers that you have. I can transfer > to the same site/modem via 9600 Z-Modem or 2400 via UUCP. So I don't think > your problem is related to the HardDrive, I have also tried putting the > uuspool: in ram to no avail. This makes sense if it's the 68030 cache problem. > I am thinking of getting UUCPPlus and seeing > if that works, also I have heard rumors that UUCP1.07 is due out in > January. I'm pretty limited in my ability to get new programs via the net. Only if they go through comp.binaries.amiga. Since that's been dead for months, it's not gonna happen soon, eh! :-/ > GoodLuck, I had my fair share of luck today. I hope this solution works for you too. > Jason Goldberg UUCP: ucsd!serene!cbmami!jason Dac -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am. -------- I cannot send or recieve mail to or from sites outside of Australia.
jeff@wisdom.UUCP (Jeff Ross) (12/27/90)
>> >> On the seemingly silly suggestion that this 'problem' with UUCP >> was only recently being seen with 68030 owners, I reverted to >> 68000 (7.14Mhz) mode, and proceeded to get my mail to RAM:, at >> 9600, without a hitch. The unfortunate side effect is that >> RNEWS/Uuxqt are real dogs in 68000 mode, and automatically start >> up when UUCICO finish. :-(. >> > I can't believe you thought my suggestion was silly ;-) Actually I >mentioned that all of us reporting the problem had 68030's, only because >people kept sending me mail saying maybe our CPU's were too slow. I never >thought that, the 68030 could be the cause. put it this way, the 68000 is fast enough to handle a feed at 9600bps, unfortunatly, I found out for about 2 weeks. I use a telebit T2500 which has a throughput (I'm guessing) of about 1400 cps when spoofing the "g" protocol. over the last too weeks, I had sent my '030 back to the company (gvp) due to some overheating problems, and durring that time, I ran stock amiga. I pull in a full news feed (about 7 meg a day of compressed data) and then uncompress and rebatch, and recompress. I am using a combination of Matt Dillion's and Frank Edward's software. Matt's does all the transfer and mail stuff, Franks does all the news stuff (its almost a full cnews port). Well, the machine was slow, but I never lost anything...I am however using ASDG's dual serial port, that may be why everything works for me. I will say this, when I was receiving a feed, and unbatching, reading news, then opened up emacs to send a message, I would type a key and have it appear a few seconds later...I thought only our vaxes did that! > So the next question is, do you run SetCPU? What version and options >do you use? It could be that we both have some type of cache set up that >UUCP doesn't like. I have sent a copy of my -x9 output to Matt Dillon in >the hopes that he can shed some light on this for us. I do run setcpu, heres the scoop: setcpu inst cache burst data cache burst fastrom > Incedently, I have a 2091 controller with SCSI harddrives and have the >same problem of no 9600 V.32 UUCP transfers that you have. I can transfer >to the same site/modem via 9600 Z-Modem or 2400 via UUCP. So I don't think >your problem is related to the HardDrive, I have also tried putting the >uuspool: in ram to no avail. I am thinking of getting UUCPPlus and seeing >if that works, also I have heard rumors that UUCP1.07 is due out in >January. I'm running with a GVP Impact controller (the older one with the newest rom) and I'm running 1.06D.10 I have 1.07, matt sent it to me about a month ago, when I started having trouble with my '030 (hardware problems it turned out) I switched back to 1.06D thinking that 1.07 was the problem, it wasn't, and I have been to lazy to switch back... > >GoodLuck, > > >-Jason- > It sounds like the serial port buffer may be getting run over...check your setting on it. >--------------------------------------------------------------------------- >Jason Goldberg UUCP: ucsd!serene!cbmami!jason >Del Mar, CA Jeff sig?!?!?! you want a stinkin' sig???? uucp: jeff@wisdom.uucp /* ...!rutgers!wisdom!jeff */ arpa: ross@fdurt1.fdu.edu MaBell: 201-299-1819