SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Strategies & Market Trends : TA-Quotes Plus

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Bob Jagow who wrote (4403)6/14/1998 5:59:00 PM
From: ftth  Read Replies (1) of 11149
 
[off topic]Hi Bob, yes exactly on the seeks and latency. That's WHY I don't understand the speed increase. I have SCSI also, so it's not really important that we resolve this, but I would like to understand where/what you're looking at to conclude this. So I'm saying the disk latency is the KEY factor, and whether we have 2 drives or not wouldn't seem to matter except on the second access. After that (except for a really, really, compute-intensive scan), calculations (microseconds) would seem to be completed way before the other drive has seeked (milliseconds), so from the second access onward, we're always waiting for the disk after each calculation,even if we have 2 disks, because no operations can truly be done in parallel.

I'm also not sure that during a scan, we're ping-ponging between 2 drives. Once the scan is set up from the first drive, all we access is the (drive with the) data, which we'll call drive 2. During the scan, seems all we access is drive 2. The executable for the scan (from drive 1)is now in the code cache.

All we can do is speculate because we don't know exactly what their code is doing. but it seems after the scan has gone thru its first initialization steps and loaded into RAM, drive 1 could be a floppy??

dh
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext