Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!rpi!pawl!shadow
From: shadow@pawl.rpi.edu (Deven T. Corzine)
Newsgroups: comp.sys.amiga
Subject: Re: Software-only network protocol standards, Again
Message-ID: 
Date: 15 Aug 89 12:32:12 GMT
References: <1789.AA1789@geo-works> <21047@cup.portal.com>
	<2109.AA2109@geo-works>
Sender: usenet@rpi.edu
Followup-To: comp.sys.amiga
Organization: Rensselaer Polytechnic Institute, Troy, NY
Lines: 31
In-reply-to: bryan@geo-works.UUCP's message of 11 Aug 89 18:48:49 GMT


On 11 Aug 89 18:48:49 GMT, bryan@geo-works.UUCP (Bryan Ford) said:

Bryan> Now, another question.  Which method would take the least
Bryan> amount of CPU (so the local user doesn't 'lose' the system too
Bryan> much): transmitting a packet at a time, at the highest speed
Bryan> the hardware can handle (i.e.  280,000 bps), and disallowing
Bryan> multitasking in between characters, or transmitting at a much
Bryan> slower speed, and using interrupts for each character?  Which
Bryan> would provide better sustained throughput?

My instinct is that the best solution is to disable multitasking, and
*maybe* interrupts, during a packet, and keeping the packet size
small.  If you disable interrupts, to keep near the recommended max of
250ms, you'd need to make the packet size about 10 bytes.  Too small
to be very useful, though you could do larger logical packets, and
send in bursts.  Assuming you can safely allow interrupts,
(questionable) you could Forbid() and send a 1K packet in about 1/30
of a second.  That, I see as reasonable.  In fact, just giving the
receiving task (if implemented as such) the highest priority in the
system, (say, 127) and the sending side a lower priority, but higher
than any compute-bound tasks, should get you reasonable performance.

Worth a try!  :-)

Deven
--
Deven T. Corzine        Internet:  deven@rpi.edu, shadow@pawl.rpi.edu
Snail:  2214 12th Street, Troy, NY 12180       Phone:  (518) 271-0750
Bitnet:  deven@rpitsmts, userfxb6@rpitsmts     UUCP:  uunet!rpi!deven
Simple things should be simple and complex things should be possible.