*BSD News Article 19492


Return to BSD News archive

Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!math.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Re: More annoyance on the DMA problem
Message-ID: <jmonroyCBqEIt.Hq4@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
X-Newsreader: TIN [version 1.1 PL8]
References: <adlerCBpvpJ.K5v@netcom.com>
Date: Sat, 14 Aug 1993 04:16:05 GMT
Lines: 72

mail adler@netcom.com
Re: Subject: Re: More annoyance on the DMA problem
 
>> Newsgroups: comp.os.386bsd.development
>> Organization: Netcom Online Communications Services (408-241-9760 login: guest)
>> Date: Fri, 13 Aug 1993 21:29:42 GMT
>>
>> In article <jmonroyCBp5Ks.CM3@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes:
>> >
>> >        MY POINT IS THE LOWER HARMONIC OF THE DMA REFRESH
>> >        COLLIDES WITH THE FDC TRANSFER.
>>
>> That's utter nonsense! Do you use the same numerology to choose
>> your lottery numbers?
>>
        MR. ALDER this is the last time I will answer you on-line.
        If you insist that I am incorrect, then send me the evidence
        or send me your theories.  I have been wrong in the past and
        I am not beyond making my errors public, in case you haven't
        noticed.
 
>> On a 4MHz PC, a refresh takes 5 clock cycles.
>>
        Where did you get this number?
        What is your source?
        What took you so long to find it?
 
>> Which means the
>> DMA request will be delayed at most 1.25 microseconds. Of course,
>> all real PCs are faster than 4MHz, but let's assume 4MHz to prove
>> my point. The 1.25 microsecs is substantially less than the 13
>> microsecond maximum inter-byte delay specified by the 8272A FDC
>> for the 500kb/s data rate.  On a real machine you might see a 400
>> nanosecond refresh delay. So how can a SUB-MICROSECOND delay in
>> servicing a DMA request cause an overrun?
>>
        Programming a DMA controller is not done in sub-microseconds,
        consider that.
 
>> I've NEVER seen any (working) device driver for the PC that was
>> caused to fail by a DRAM refresh cycle. I've worked on at least five
>> different unix floppy drivers. None of them ever failed due to
>> a refresh cycle.
>>
        I can only repeat what I said earlier.
 
        Earlier you stated that "someone" would be looking at
        the DMA problem with the FDC ... today you seem to be
        the expert.
        I can only question your motives personally.
 
----
 
        If you insist on proving your incompetance on-line that
        is your business, but I can not support you.
 
        My numbers are all verifiable, consider this in your
        next statement.
 
        If you have some helpful suggestions, some keen insight,
        a clarviant perception, or even a minor mathematical
        experience, then please   by  all  means  post.
        IF NOT, e-mail me and let clear this up.
        Don't waste the Nets time with your ranting.
 
 
        Thank your for your attention.
___________________________________________________________________________
Jesus Monroy Jr                                          jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________