[Coco] Benchmarking and Performance (Was Re: Preserving old CoCo diskettes...)

Boisy G. Pitre boisy at tee-boy.com
Tue May 18 23:46:28 EDT 2010


Roger,

My understanding is that the hardware was designed by Darren.  If I'm wrong on that point, then the misunderstanding is mine, and I apologize.

Megaread is a valid benchmarking utility for how a device will perform under NitrOS-9 relative to other devices, with *relative* being the operative word.  While the absolute numbers may not be exactly representative of how fast a device reads a megabyte of data (taking into account interrupts and OS overhead), the comparison of megaread times to other devices is a valid one.

You are welcome to (and should) post the latest megaread timings as you improve your driver.  If you can improve the performance > 3X by going from ~240 seconds to ~69 seconds just by doing something different in your driver, then great.  As it stands, the current megaread times are:

rbdw3: 120 seconds.
SuperIDE/SD with SuperDriver 2.1: 22 seconds
SuperIDE/CF with SuperDriver 2.1: 18 seconds
TC^3 SCSI with SuperDriver 2.1: 12 seconds (I believe this is with turbo mode in the driver turned on)

Is your ego so easily bruised that you cannot take an honest suggestion? It was not my intent to be insulting to you in recommending SuperDriver. On the contrary, I was trying to be helpful and suggest something to make your work easier. You're certainly free to do your own driver.
--
Boisy G. Pitre
http://www.tee-boy.com/

On May 18, 2010, at 9:24 PM, Roger Taylor wrote:

> At 08:23 PM 5/18/2010, you wrote:
>> Roger,
>> I won't say it's a bad solution, but I take issue that it is the best.  It's ok to be proud of something, but when you say it is the best, you should be ready to back that opinion up with quantifiable data.
>> As well you should.  Darren Atkinson did a great job designing the hardware, and you've done a nice job marketing it.
> 
> 
> If we're going to do this in the forum, the least you guys could do is tease a little, maybe bait me a few times.. you know, the usual tricks?  Hell no, here we go Already.  But the gloves are coming off this time.  :)
> 
> I can see you took the time to craft an overall witty reply to Mark's request for you to jump into this conversation he so-politely hijacked from Gene and I, but nothing you said has a single point.
> 
> Look, I'll go another round with both of ya, but you have GOT to get some sleep or this isn't going to turn out good.  You've both been on the road for a while and maybe just a little groggy.
> 
> Nobody over here ever said a negative word about one of your products or even mentioned a single word about your stuff.  I bring up the word "6551" and howdy-doody, here they come again.
> 
> Boisy, are you claiming that Darren completely designed the boards, or are you claiming that we co-designed them, and who do you think did the firmware as well?  % vs. %, I demand to know the whole story and who did what.  Don't hold back, Boisy!!  Tell it ALL to the whole class or sit your butt back down, but please don't come in here with a half-ass story and think I'm going to keep totally quiet.
> 
> 
> 
>> > I forgot to mention, on this firmware benchmark thing: the early OS-9 drivers for the Drive Pak read card-LSN0 on each sector transfer, so there was 1024 card bytes read for every 256 CoCo bytes requested.   Today's driver cuts that in half.  Tomorrow's driver will cut that in half when I move to the deblocking scheme.  If I can get the megaread (not really a good tool) down to 1:09 or so, I'm happy with this, but I won't trade a single bit of quality or stability just to meet somebody else's expectations of what a false benchmark should show.
>> 
>> Megaread doesn't have a lot of bells and whistles, but it has been a standard for measuring throughput on the CoCo under OS-9 for near two decades.
> 
> 
> I'm glad somebody admitted that the program is older than the dinosaurs.  Thank you for clearing that up!  Now drop down to DOS and do some more testing on ALL DEVICES you're benchmarking.  Post those results as well.  I'll be here.  I'm not going anywhere.
> 
> 
>> As someone who sells CoCo hardware, you should expect it to be benchmarked and tested for performance.  This is not an attempt to knock your product; it merely states what its performance is relative to other devices.
>> The current megaread time for your pak with an SD card is around 254 seconds or so.  It sounds like you've identified the issues that are causing less than ideal performance, so it would be great to see how subsequent generations of your driver stack up.
> 
> 
> Texas Bullshit, Boisy!  You want to quote the results from an early OS-9 driver, that's fine with me.  I've got 35 more paks to build and I don't have time for this crap.  I clearly said that two sectors were being read for each transfer in the earlier drivers, and you Clearly "benchmarked" that pak.  Thank You.
> 
> The OS-9 partition w/ new drivers can be downloaded to the pak quite easily, so why is this a hardware issue?
> 
> 
>> As for deblocking, SuperDriver handles this very well and has a myriad of other features.  You could save yourself a lot of time and write a low level driver that plugs right into SuperDriver.  The documentation is online at www.cloud9tech.com and the product comes with a sample low level driver that you can start with.  All you need to do is write the low level routines to talk to your device and hand back the data according to the documented specifications.  You get partitioning, deblocking, write verification, automatic drive size querying, and smart caching all for free.
> 
> Now you're telling me I can't handle a simple native sector split?  And that I need documentation?  Are you purposely insulting me or did it just happen by mistake about 8 times in one message?
> 
> Boisy, and Mark.......  come on guys!!!!!  Jesus Christ.
> 
> 
> 
> -- 
> ~ Roger Taylor
> 
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco




More information about the Coco mailing list