Re: [Freedos-user] IDE <-> CF adapters
Dec 27, 2020 12:05:46 AM Frantisek Rysanek : > On 26 Dec 2020 at 22:40, Jon Brase wrote: >> > 40 MB of RAM in Windows95 - that's something I once had in a Pentium > 75 MHz :-) Possibly the same model of machine, given that both RAM and CPU match, and 40 MiB is a rather idiosyncratic amount of RAM (add opposed to a power of two). Mine's an AST, forget the exact model number and can't check right now. > > Linux on 40 MB of RAM... there was a time this was perfectly okay, > including a GUI. I believe something like RedHat 6.2 or Debian 3-4 > would fly on that setup. Currently it's running Debian 4, with a repository mirror served from my main desktop. I've run the numbers, and 6 should be able to run too, but it's actually the installer that constrains things. Debian 6 doesn't have drivers for older PATA stacks in the initrd for the install medium, and needs more memory than 40 MiB before it gets to the point in the installer where it can load additional drivers, so it can't mount swap early enough and fails to install. Debian 4 is able to recognize the HDD from the get-go, and can thus use swap to get around memory limitations. I think an in-place upgrade 4 -> 5 -> 6 should let me get Debian 6 onto the machine, and that project is planned after the migration to new storage. > I haven't seen a harddisk of that era for a decade or so, and I don't > recall testing one with hddtest - but based on the average seek times > quoted in the old days (12 to 16 ms), and based on the audio > impression I recall, I'd say that the hard drives of that era would > exceed 25 totally random IOps. Modern 7200rpm desktop SATA drives > during the last 15 years can typically achieve some 75 random IOps. > About 60 IOps for laptop drives. And those numbers do not grow > significantly during the years, with new disk drive generations. OK, if modern SATA gets 75, then 25 isn't too concerning. I was worried it might be more like an order of magnitude (or two) difference. > > and I'd like to say that you consistently respond in a way that makes > me believe that you know your trade, when it comes to partitioning > and the various size boundaries - you have my thumbs up :-) > Thanks! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
On 26 Dec 2020 at 17:13, Dale E Sterner wrote: > I've been using the same cf card for years. OS's > 2000 an higher can only run on KomputerBay cf chips. > These versions of windows check for fixed or removable. > XP will give you a memory error on a Sandisk card but > it still will run poorly. > Sandisk does make a fixed version but you can't buy them. > Only industrial customers can buy Sandisk fixed versions. > I tried ; they hang up on you. > > cheers > DS Innodisk are almost strictly industrial, and they assemble to order (or have stock) from single pieces up, aiming for long-term product lifecycles/availability. Consequently the lead time is a few days EXW, plus transportation to wherever in the world you are. They probably wouldn't sell to individual customers directly, but you should try talking to a local distributor advertising their stuff. Some disties may have a modest stock of some CF model that might as well suit your needs off the shelf. Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
On 26 Dec 2020 at 22:40, Jon Brase wrote: > > Actually I anticipate swap usage at about double physical RAM (for a > total memory usage of 3x physical RAM). I'm using Debian to > administer the machine (with DOS/Win95 for actual retrocomputing), > and empirically that runs well (shell only) with that amount of swap > (at least with the swap partition on a magnetic disk). If I start > XFCE, then it starts thrashing, but I don't really need a graphical > environment there. > [...] > As above, I'm not going for quite 4x RAM for swap, but the exact > numbers in the current magnetic disk configuration are 40 MiB RAM, > 80 MiB swap, and I plan to overprovision swap significantly on CF to > spread out write wear. Part of what I'm trying to figure out is what > kind of overprovisioning I'll need to get a decent lifetime for the > swap device. > 40 MB of RAM in Windows95 - that's something I once had in a Pentium 75 MHz :-) and it worked pretty well for the applications of that time. So suppose that you give it 128 MB of swap, on a 1 GB drive. That will extend the lifetime 8 times compared to a Flash drive with exactly 128 MB, if using the same NAND technology. But again it's really the cumulative number of write transactions, rather than the size of the swap file, that is inversely proportional to calendar lifetime. And again I cannot quantify this any better or absolutely. Linux on 40 MB of RAM... there was a time this was perfectly okay, including a GUI. I believe something like RedHat 6.2 or Debian 3-4 would fly on that setup. Obviously it would have an ancient web browser and e.g. when editing photoes you might run into the limit of available RAM :-) 40 MB should actually be enough even for modern kernels to boot, but a modern user space probably wouldn't be happy, even with some lightweight WM / desktop. > > Don't be surprised to see 25 IOps or even > > less, pauses lasting a couple seconds etc. A pretty far cry from > > those ~4k IOps that you might come to expect, based on random > > read performance. > > 25 IOps doesn't sound good. How does that compare to a similar I/O > pattern on a late 90s/early 2000s magnetic disk? > I haven't seen a harddisk of that era for a decade or so, and I don't recall testing one with hddtest - but based on the average seek times quoted in the old days (12 to 16 ms), and based on the audio impression I recall, I'd say that the hard drives of that era would exceed 25 totally random IOps. Modern 7200rpm desktop SATA drives during the last 15 years can typically achieve some 75 random IOps. About 60 IOps for laptop drives. And those numbers do not grow significantly during the years, with new disk drive generations. These are unapologetic figures, with seeks genererated by /dev/urandom and "direct access" (no caching). The random seek positions alone pretty much prevent any cache from being effective :-) > Well, the absolute ideal for swap, if I could find it, would be an > IDE device that used a couple GiB of modern DRAM and initialized > itself at boot from some partitioning plan > exactly :-) > > > I actually wanted to say this: if you > > only have use for maybe 1 GB of swap, it's no problem that your > > partition can only be 2 GB, > > Actually only 512 MiB for anything DOS will be touching (or when > BIOS first sees the drive), but that won't be a problem for the > Linux swap partition once I've done the whole "trick the BIOS" > dance. > and I'd like to say that you consistently respond in a way that makes me believe that you know your trade, when it comes to partitioning and the various size boundaries - you have my thumbs up :-) Frank ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
Dec 26, 2020 3:47:44 PM Frantisek Rysanek : > I've noticed that you want to have about 4 times the swap space > compared to physical RAM. This means to me that your historical > machine is starved of RAM, and you envisage enhancing the volume of > RAM by a quick swap space. Hmm. > The actual success of that idea will depend on how large your typical > "DRAM working set" actually is. Actually I anticipate swap usage at about double physical RAM (for a total memory usage of 3x physical RAM). I'm using Debian to administer the machine (with DOS/Win95 for actual retrocomputing), and empirically that runs well (shell only) with that amount of swap (at least with the swap partition on a magnetic disk). If I start XFCE, then it starts thrashing, but I don't really need a graphical environment there. > It gets worse. If your machine thrashes the swap space intensively, > generating lots of those tiny write transactions, a typical CF card > will quickly get its relatively tiny transaction buffer (and "SLC > zone", if used) full of pending writes and will slow down noticeably > at the outer ATA interface. Don't be surprised to see 25 IOps or even > less, pauses lasting a couple seconds etc. A pretty far cry from > those ~4k IOps that you might come to expect, based on random read > performance. 25 IOps doesn't sound good. How does that compare to a similar I/O pattern on a late 90s/early 2000s magnetic disk? > > Try comparing your CF-based swap-on-flash solution with an > alternative setup, using some SATA-based SSD/CFast/mSATA > and a SATA/IDE converter. How about converting this all the way to a > small Optane drive :-) Those have like 6k of permitted overwrites, if > memory serves - and have really short latencies. Except that ehh... > they seem to be NVMe = PCI-e based, rather than SATA. Ahh well. Well, the absolute ideal for swap, if I could find it, would be an IDE device that used a couple GiB of modern DRAM and initialized itself at boot from some partitioning plan (for instance "1 Linux swap partition", or "1 Linux swap partition, 1 empty FAT partition"), or an image on a read only flash device. There's no need for a swap device to actually be non-volatile (beyond keeping formatting information for the OS to recognize it as a swap device), and DRAM doesn't have write limits. > I can't seem to find any figure, how much RAM your machine actually > has, just that you want 4 times that much in swap. As above, I'm not going for quite 4x RAM for swap, but the exact numbers in the current magnetic disk configuration are 40 MiB RAM, 80 MiB swap, and I plan to overprovision swap significantly on CF to spread out write wear. Part of what I'm trying to figure out is what kind of overprovisioning I'll need to get a decent lifetime for the swap device. > I actually wanted to say this: if you > only have use for maybe 1 GB of swap, it's no problem that your > partition can only be 2 GB, Actually only 512 MiB for anything DOS will be touching (or when BIOS first sees the drive), but that won't be a problem for the Linux swap partition once I've done the whole "trick the BIOS" dance. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
I've been using the same cf card for years. OS's 2000 an higher can only run on KomputerBay cf chips. These versions of windows check for fixed or removable. XP will give you a memory error on a Sandisk card but it still will run poorly. Sandisk does make a fixed version but you can't buy them. Only industrial customers can buy Sandisk fixed versions. I tried ; they hang up on you. cheers DS On Fri, 25 Dec 2020 22:24:42 +0100 "Frantisek Rysanek" writes: > On 24 Dec 2020 at 13:10, ZB wrote: > > On Tue, Dec 22, 2020 at 02:37:44PM +0100, DosWorld via > Freedos-user > > wrote: > > > >> 1. This is bad idea - use flash cards for swap or more modern os > >> (like all windows). I had experience with 16 TF cards, which die > >> after 1 year (rewrite limit). All 16 cards work in non-overloaded > >> machines. > > > > My CF card is used as "HDD" 3rd month - we'll see in 9 months will > > it survive. > > > > I doubt it "must die" after a year of use - consider all that > > photocameras that use CF cards; their owners probably had to buy > new CF > > cards each year. > > > Practical experience, using CF cards as a boot drive in > "miscellaneous embedded/industrial" computers where the OS and disk > don't have much to do: > > A) standard desktop Windows (XP or earlier) with swapping left > operational, 1 year of lifetime sounds about right. > > B) Windows Embedded (XP or later) with swap turned off and > preferably > with the drive operated in read-only mode (Write Filter enabled): > the CF card would live forever. > > Note that if you need to use the flash drive as a swap medium, with > SLC you have roughly 20 times the lifetime, compared to MLC. > > But it's generally advisable to avoid swapping altogether. Also > think > about logging, Windows updates etc. > > We've also seen MLC CF cards die after 3 months, when used as the > system drive in a SCADA machine, where the software kept making a > backup of the current "state" as often as it could (writing a chunk > of data to a file on the flash a couple times per second, > apparently). > > Swapping means writing tiny transactions (4 kB) at random offsets, > which practically means that the dual-stage mapping mechanism to > flash rows and erase blocks will have a lot of janitoring to do. > This will multiply the volume written. > Compared to that, photoes are stored in pretty much sequential > fashion (JPEG's, each several MB in size) and there are not nearly > as > many of them as the number of writes coming from Windows that keep > running 24x7. How many photoes can a human shoot - a couple dozen a > day? A couple hundred? > > When using smal flash form factors as boot drives (CF, similar IDE > Flash "plugs" or SD for instance, CFast, mSATA or M.2), avoid > wishful > thinking. > And, 2.5" Flash SSD's are not necessarily better. > I'm speaking machines for business/industrial use. > If this is a toy machine, you probably have your own idea :-) > > >> 2. Use last generation of motherboard for Pentium-1 (as minimum) > >> with VIA Apollo chipset (designed for Pentium and Amd K6/K6-2) - > >> only this chipset understand ATA100 native and allow connect CF > >> via simple IDE-CF reductor > > > > I use that CF card with old 486 Soyo-SiS mobo (and the "simple > > reductor"). > > > >> (intel VX/HX - NO). As i understand, problem is - no support > >> ATA100 in older IDE-controllers. In other case, you need use > >> PCI-IDE cards or special modern ISA-IDE controllers (designed > >> specially for use with CF). > > > > I use that CF card with old VLB IDE controller. Seems to be > working > > just fine, the only problem is 2 GB limit; it can't "see" any > larger > > partition. > > Anyway it's not related to CF card, but to controller rather > > > CF cards are generally backwards compatible with the old PIO modes > (DMA-less transfers, polling for every single byte). > Thus, in theory, they should work against any old IDE controller. > A CF card that supports UDMA100 should run just fine in a system > that > can only do PIO, or run limited to UDMA33 for instance. > > As for size limits, I agree that some BIOSes did actually have such > a > limit in the past. It doesn't seem to be an inherent limit of > IDE/ATA > or LBA28 (those have other limits of their own). > Other than that, 2 GB is a limit of FAT16, per volume = not > necessarily a BIOS issue. Though I cannot rule out that a particular > > BIOS would in fact inspect the partition table and would not approve > > of partitions larger than some arbitrary size :-) Over the years, > I've seen various "innovative BIOS heuristics" in the boot sequence. > > http://www.dewassoc.com/kbase/hard_drives/hard_drive_size_barriers.htm > https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html > https://en.wikipedia.org/wiki/Comparison_of_file_systems > > And another matter is that, especially in the old days, the ATA > flash > target controllers (and their firmware) were not as
Re: [Freedos-user] IDE <-> CF adapters
On 25 Dec 2020 at 22:36, Jon Brase wrote: > Dec 25, 2020 3:26:42 PM Frantisek Rysanek > : > > > A) standard desktop Windows (XP or earlier) with swapping left > operational, 1 year of lifetime sounds about right. > > It sounds like you're using the card for the OS + swap, though, > rather than having separate cards for the OS and swap. My plan is to > separate them, and probably to overprovision the swap device > significantly. > allright - using a dedicated physical CF card for swap, and another one for the system itself, is definitely a good idea. As a way of protecting the OS boot files. If the swap drive dies, the system boot drive will likely survive, and you only need to replace and format the dedicated swap drive. It's a good start. As for the question if this is good enough, even with the dedicated swap drive, depends on your actual circumstances (swap load = volume and patterns). I suggest that you try this with a cheap MLC card for the swap drive and see how long it survives in your daily practice. And then maybe consider switching to an SLC card to get 20 times the endurance. Trying to protect your system boot partition by making a dedicated swap partition, on a shared flash drive, is moot / futile. The two layers of block mapping below LBA are oblivious of your partitioning above the LBA layer. The wear leveling mechanism inside the drive will happily shuffle blocks belonging to your "read only system boot partition" and mix them with the volatile swap partition, under the hood - for the sake of keeping the erase count per erase block level across the space of the underlying NAND chips (to utilize the available erase count evenly). When unrecoverable errors inevitably start to occur, the drive as a whole is gonna die, your system boot partition won't be accessibe either. I've noticed that you want to have about 4 times the swap space compared to physical RAM. This means to me that your historical machine is starved of RAM, and you envisage enhancing the volume of RAM by a quick swap space. Hmm. The actual success of that idea will depend on how large your typical "DRAM working set" actually is. If you have a flock of apps running at the same time, allocating lots of virtual memory, but only a fraction of that virtual memory needs to be in RAM at any one time (a timespan of say a couple dozen seconds), you're good to go. I can imagine a scenario where you have a myriad desktop apps open, but most of them are just waiting on the taskbar and are out of focus - so that Windows swap them out eventually, which causes no sorrow. But if you need to have much of that virtual space in the "working set" at the same time, your solution with a flash-based drive probably won't satisfy you, performance-wise. If I consider a single channel of 64bit PC133 SDRAM (for instance), that's 1 GBps of sequential transfer rate. UDMA100 is only 100 MBps at its very best. Also, while the latency of your RAM is about 60 ns, for the CF card it's possibly a couple hundred microseconds for reading. It gets worse. If your machine thrashes the swap space intensively, generating lots of those tiny write transactions, a typical CF card will quickly get its relatively tiny transaction buffer (and "SLC zone", if used) full of pending writes and will slow down noticeably at the outer ATA interface. Don't be surprised to see 25 IOps or even less, pauses lasting a couple seconds etc. A pretty far cry from those ~4k IOps that you might come to expect, based on random read performance. => If you're serious about upgrading your legacy machine in this way, I suggest that you purchase two CF/IDE adaptors and some cheap CF card and try for yourself. If you have a chance to test your CF cards on an IDE channel under Linux, consider trying this simple proggie of mine: http://support.fccps.cz/download/adv/frr/hddtest-1.1.tgz There are certainly other load generators / benchmarks. And there's the iostat tool, from the Sysstat package, which can show you the IOps load at the block layer, generated by any kind of software. Don't trash the CF card with random *writes* for too long, as such a test quickly eats away its available erase count. Try comparing your CF-based swap-on-flash solution with an alternative setup, using some SATA-based SSD/CFast/mSATA and a SATA/IDE converter. How about converting this all the way to a small Optane drive :-) Those have like 6k of permitted overwrites, if memory serves - and have really short latencies. Except that ehh... they seem to be NVMe = PCI-e based, rather than SATA. Ahh well. I can't seem to find any figure, how much RAM your machine actually has, just that you want 4 times that much in swap. AFAICT Windows 98 had a problem using more than 512 MB of physical RAM, not sure about how much swap they could use - but let's assume that 4 GB total would be a maximum for a 32bit OS. I actually wanted to say this: if you only have use for
Re: [Freedos-user] Question about FDAPM
Thanks Eric! I had noticed that FDAPM POWEROFF did both a flush and spindown, but after a couple of seconds it says "Warming up...Back...Back on..." so I wasn't quite sure what it had done. In any case, it sounds like I should be ok holding down the power button at that point. This particular laptop has a very minimal bios, at least the part I can access. On Sat, Dec 26, 2020 at 10:43 AM Eric Auer wrote: > > Hi Marv! > > FDAPM FLUSH (no slash needed) does not rely on the BIOS, > it is just meant to give caches hints to write back all > pending writes. Note that none of the caches shipping > with FreeDOS will pool or delay writes, so you actually > do not need to flush with those :-) > > As soon as the last app returns to the prompt, you can > expect that DOS has written all data and closed files. > > The flush command should work for the following caches: > msclient (not a cache, but network drives), CD Blitz, > PC-Cache, QuickCache, Super PC Kwik / QCache, SMARTDRV. > It also tells DOS and BIOS disks to reset some state. > > The latter could help to make sure that things are > written from the built-in cache of your SD card to > the permanent storage of that card. I would expect > most drives - including SSD and SD ones - to default > to not delay writes unless you enable that? And how > long would such delays be at most? Are there rules > about it? Or experiences here on the list? > You could use the SPINDOWN command to tell disks/SD > to shut down - that should give them a hint to flush > their built-in caches :-) Actually, FDAPM POWEROFF > implies flush and spindown anyway. > > Regards, Eric > > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- It's all fun and games until someone divides by zero. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Question about FDAPM
Hi Marv! FDAPM FLUSH (no slash needed) does not rely on the BIOS, it is just meant to give caches hints to write back all pending writes. Note that none of the caches shipping with FreeDOS will pool or delay writes, so you actually do not need to flush with those :-) As soon as the last app returns to the prompt, you can expect that DOS has written all data and closed files. The flush command should work for the following caches: msclient (not a cache, but network drives), CD Blitz, PC-Cache, QuickCache, Super PC Kwik / QCache, SMARTDRV. It also tells DOS and BIOS disks to reset some state. The latter could help to make sure that things are written from the built-in cache of your SD card to the permanent storage of that card. I would expect most drives - including SSD and SD ones - to default to not delay writes unless you enable that? And how long would such delays be at most? Are there rules about it? Or experiences here on the list? You could use the SPINDOWN command to tell disks/SD to shut down - that should give them a hint to flush their built-in caches :-) Actually, FDAPM POWEROFF implies flush and spindown anyway. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Question about FDAPM
One of my FreeDos machines is a laptop without APM. The only way to shut it down is to hold the off button for several seconds. That is not my preferred way of doing things. Some FDAPM commands seem to work (meaning I don't get any error msg) without the computer having APM, for example, FDAPM /FLUSH. So, I've gotten into the habit of doing that before holding down the off button. But does FDAPM /FLUSH really work in my case? I haven't had any problems that I know of so far. In particular, I'm concerned about the 32GB SD card I use for transferring files back and forth to my Windows machines. -- It's all fun and games until someone divides by zero. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
