Stack speed, system performance

Open forum is for the discussion of the Uther ethernet board for the Apple II series of computers.

Moderator: support

Stack speed, system performance

Postby David Schmidt » Fri Sep 01, 2006 10:25 pm

As I'm exploring how I'd have to modify ADTPro to use the Uthernet card, a question of performance comes to mind. ADT and ADTPro use RLE compression to minimize the number of actual bits it has to pump out on the wire; there's non-negligible time spent in compression/decompression. Would it make a difference in the Uthernet world? If I stuff 512 bytes of data in a packet or compress it down to 128, will that alter the transmission speed a lot?

I suppose this has a lot to do with the stack itself and how bits are transferred from memory to card. But short of doing some physical tests - are there any experience reports out there about where more time is spent: moving memory around, or shifting bits out on the wire?
David Schmidt
 
Posts: 41
Joined: Tue Aug 29, 2006 6:55 pm
Location: USA

Re: Stack speed, system performance

Postby support » Fri Sep 08, 2006 9:18 am

David Schmidt wrote:As I'm exploring how I'd have to modify ADTPro to use the Uthernet card, a question of performance comes to mind. ADT and ADTPro use RLE compression to minimize the number of actual bits it has to pump out on the wire; there's non-negligible time spent in compression/decompression. Would it make a difference in the Uthernet world? If I stuff 512 bytes of data in a packet or compress it down to 128, will that alter the transmission speed a lot?


Since you are prereading/processing a chunk of disk at a time I think it would make sense to still compress the data and then pack as many 1500 bytes frames as possible from there. Overall through put is governed by CPU speed (how fast can they be sent to the chip - if there is less to send, the better.

David Schmidt wrote:I suppose this has a lot to do with the stack itself and how bits are transferred from memory to card. But short of doing some physical tests - are there any experience reports out there about where more time is spent: moving memory around, or shifting bits out on the wire?


The CPU writes a byte at a time and the cs8900a stashes it in it's own buffers until the frame is complete and it is ready to send.

It would be nice if the compression was optional so we could test it with and without for various disk images.

Glenn
support
Site Admin
 
Posts: 169
Joined: Tue Mar 08, 2005 10:49 pm
Location: Ajax, On, Canada

Re: Stack speed, system performance

Postby David Schmidt » Sat Sep 09, 2006 9:39 am

support wrote:Since you are prereading/processing a chunk of disk at a time I think it would make sense to still compress the data and then pack as many 1500 bytes frames as possible from there. Overall through put is governed by CPU speed (how fast can they be sent to the chip - if there is less to send, the better.

Worst case, I would have a multiple of 512 bytes to send (i.e. one disk block) that could potentially be uncompressible. Not likely, but possible. That would be 1536 bytes of payload (plus, what, 6-8 bytes of my control data). What is the max frame size again? I must be getting close to the limit.

If that's too much, then it'll have to scale back to just 2 blocks at 1024 bytes. (And there's no requirement that disks have an even number of blocks, so there'll have to be some smarts at both ends to take care of that too.)

support wrote:It would be nice if the compression was optional so we could test it with and without for various disk images.

Agreed. That would be a nice feature to play with. A simple matter of programming. :-)
David Schmidt
 
Posts: 41
Joined: Tue Aug 29, 2006 6:55 pm
Location: USA

Re: Stack speed, system performance

Postby support » Sat Sep 09, 2006 9:53 am

David Schmidt wrote:Worst case, I would have a multiple of 512 bytes to send (i.e. one disk block) that could potentially be uncompressible. Not likely, but possible. That would be 1536 bytes of payload (plus, what, 6-8 bytes of my control data). What is the max frame size again? I must be getting close to the limit.


1500 bytes .... so it looks like two blocks max without compression

David Schmidt wrote:If that's too much, then it'll have to scale back to just 2 blocks at 1024 bytes. (And there's no requirement that disks have an even number of blocks, so there'll have to be some smarts at both ends to take care of that too.)


:)
support
Site Admin
 
Posts: 169
Joined: Tue Mar 08, 2005 10:49 pm
Location: Ajax, On, Canada

Postby KPR » Mon Oct 30, 2006 12:52 pm

Any Status change on this??

It would be so cool to be able to do a disk transfer via uthernet.. also is there any way to do the original boot disk that way as well??

K.
KPR
 
Posts: 8
Joined: Fri Oct 27, 2006 11:11 am

Postby David Schmidt » Mon Oct 30, 2006 2:46 pm

KPR wrote:Any Status change on this??

Right now I have a packet send and receive layer working. I just finished the user interface to configure the IP parameters at the client end last weekend.

I have one nagging problem, though: occasionally, the checksum of a packet is calculated incorrectly, so it never gets past the next piece of network hardware it encounters (typically a swtich). So sending isn't reliable yet. It's most likely a bug on my part, but it's proving to be a time sink. WireShark showed me what's wrong in the packet, but it's my code's interaction with ip65 that is causing the real problem. At least it's repeatable; the same blocks consistently cause the same problem, and all others are always fine.

KPR wrote:It would be so cool to be able to do a disk transfer via uthernet..

It is kinda cool. :-) Initial tests ran about 25% faster than 115kbps.

KPR wrote:also is there any way to do the original boot disk that way as well??

I assume you mean the bare-metal bootstrap process. That would be tough. There's not really an IN#2 kind of thing you could do with the Uther card to get the stack shifted over to the Apple. I think we're still stuck with serial communications for that task.
David Schmidt
 
Posts: 41
Joined: Tue Aug 29, 2006 6:55 pm
Location: USA

Re: Stack speed, system performance

Postby David Schmidt » Mon Oct 30, 2006 2:58 pm

David Schmidt wrote:Worst case, I would have a multiple of 512 bytes to send (i.e. one disk block) that could potentially be uncompressible.

Ooops, worst case of a disk block that is uncompressible means RLE actually makes it grow by 50%-ish. So let's pretend that block actually takes 768 bytes. Stack two of those together, and we're at 1536 + control bytes. So, we're down to one block per packet again. Fortunately, that fits with the control logic very well. ;-)
David Schmidt
 
Posts: 41
Joined: Tue Aug 29, 2006 6:55 pm
Location: USA

Re: Stack speed, system performance

Postby David Schmidt » Thu Dec 28, 2006 6:06 pm

support wrote:It would be nice if the compression was optional so we could test it with and without for various disk images.


I am playing with some of your suggestions now. It turns out that sending uncompressed blocks does slow things down. I.e. I save more by doing differential RLE and sending that than not compressing at all. A sparse 140k disk image took 20.6sec to send with RLE, and 25.3sec to send without. So, the fewer bits to send... the better.
David Schmidt
 
Posts: 41
Joined: Tue Aug 29, 2006 6:55 pm
Location: USA

Re: Stack speed, system performance

Postby support » Thu Dec 28, 2006 11:05 pm

David Schmidt wrote:
support wrote:It would be nice if the compression was optional so we could test it with and without for various disk images.


I am playing with some of your suggestions now. It turns out that sending uncompressed blocks does slow things down. I.e. I save more by doing differential RLE and sending that than not compressing at all. A sparse 140k disk image took 20.6sec to send with RLE, and 25.3sec to send without. So, the fewer bits to send... the better.


Hmm yes 20% faster is a lot .... :)

Thanks for the update ...

Glenn
support
Site Admin
 
Posts: 169
Joined: Tue Mar 08, 2005 10:49 pm
Location: Ajax, On, Canada


Return to Uther - General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron