home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / amiga / programm / 13121 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.0 KB
  1. Path: sparky!uunet!uunet.ca!canrem!dosgate![jonathan.forbes@canrem.com]
  2. From: "jonathan forbes" <jonathan.forbes@canrem.com>
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: writing odd bytes
  5. Message-ID: <1992Sep6.848.16300@dosgate>
  6. Date: 6 Sep 92 02:33:46 EST
  7. Reply-To: "jonathan forbes" <jonathan.forbes@canrem.com>
  8. Distribution: comp
  9. Organization: Canada Remote Systems
  10. Lines: 37
  11.  
  12. I have run into a very strange problem.  In one of my programs, a
  13. Write() call will occasionally take *much* longer to execute than it
  14. should (when writing to any hard drive).  When this happens, it would
  15. seem to be a slowdown to about 25% of "normal" speed, and the hard drive
  16. activity light is solid.
  17.  
  18. It's almost as if the data was being written a little bit at a time, but
  19. I have checked and only large pieces are being written (~= 64k).
  20.  
  21. Now, the strange thing I noticed eventually is that writing an odd
  22. number of bytes seems to make it happen; I can write 65534 or 65536
  23. bytes, but if I write 65535 bytes, it slows down.
  24.  
  25. Even weirder; I wrote a tiny program to try to test this out (writing
  26. 65535 bytes ten times to a new file) but it didn't have any effect
  27. there.
  28.  
  29. Note that even though it takes 4 times long to write the data, the data
  30. written *is* correct.
  31.  
  32. I have *no* idea what could cause this; perhaps it's something internal
  33. to DOS, and for some reason DOS decided to write out the data in small
  34. pieces (maybe my program wrote over something critical to cause such a
  35. thing?  but if so, why only for odd byte amounts?)
  36.  
  37. I also tried making the program write (Size+1) bytes if Size was odd,
  38. and then doing a Seek() backwards one, but that also incurred the same
  39. slowdown for some odd reason...
  40.  
  41. The problem does not occur when I am writing to a RAM: disk, but it
  42. occurs on all of my hard drives.
  43.  
  44. Anyone run into this problem before or have *any* light to shed on this
  45. matter?  I'm rather confused...
  46. --
  47. Canada Remote Systems  - Toronto, Ontario/Detroit, MI
  48. World's Largest PCBOARD System - 416-629-7000/629-7044
  49.