NVMe device driver

@tonyw

The current release on os4depot will crash when no NVMe drive is found.

I will upload a new version soon which solves this issue.

On top of that there might be quality issues with the X5000. I get IO timeouts when I use the X1 slot in front of the Xena slot. The other slots work fine for me.

@geennaam

I tried a 500 GB NVMe card in an M.2 to PCI-e adaptor. As I indicated to you in private email last week, the X5000/20 crashes at boot with the driver in Kicklayout. It does not matter in my machine whether the adaptor card is plugged in or not, it still crashes.

I tried the adaptor card in the x16 slot beside the video slot. I have not tried it in any of the X1 card slots. I also have not tried the card in any other machine.

I have every NG machine here, so I can check the driver in any platform and provide crash logs or other data, if you wish.

It is possible that my up-to-date platforms behave differently from the older installation you are using for development. Another reason to investigate.

@tonyw

OK, I see the email now. Somehow we overlook each other's emails. I've send you an email some time ago about the transfer limit but never got a reply.

I will send you my latest beta driver this weekend. It should not crash anymore. I will also send you a probe which will probe all NVMe drives in your system.

@tonyw

On the X5000 yes.
I used the x4 slot.

@geennaam

Have you already tested the speed of NTFS and FAT partitions with your driver? When I tested NTFS (using the copy command from enhancer package and a 1GB file), I got 84 MB/s for NVMe->RAM and 66 MB/s for RAM->NVMe. Much slower than I expected...

@Rolar

No I haven't. But as you can read above. The driver itself manages well beyond 1GigaByte/s. The limitation is in the filesystem.

@Rolar
Using C:Copy from/to RAM: for benchmarks doesn't make any sense, and it's not comparable at all if you don't even include the BUF size you used in the results (the default is way too small).
Even using DiskSpeed is much better than that.

With the C:Copy test only a small part depends on the speed nvme.device and it's hardware, you are benchmarking 4-5 different things at the same time instead:
1. Speed of the C:Copy implementation. Unless a lot in the AmigaOS version changed and was improved, or even better it was reimplemented from scratch, it's a very slow way for copying files and for example ASyncWB is much faster. Additionally the AmigaOS C:Copy and the Enhancer C:Copy are completely unrelated software. Same goal, but independent implementations. For example you can't use the Enhancer C:Copy for results comparable to results from someone else who is using the AmigaOS C:Copy instead.
2. Speed of RAM-Handler. For example RAM-Handler versions using ExtMem are very likely slower than older versions without ExtMem support.
3. Speed of the file system used on the nvme.device partition.
4. Speed of the disk cache used by the file system. For example with SFS either it's external (diskcache.library) or internal cache system (diskcache.library.kmod disabled or removed from the Kicklayout), but most other file systems probably have internal disk caches as well. The speed of the caches depend on the IExec->CopyMemQuick() speed and can be very different on different Amiga NG systems, and for example both of the SFS caches don't include any of the required optimisations for CPUs with 64 byte cache line sizes but only have support for the older, 32 byte cache line CPUs.
5. nvme.device and the NVMe hardware.

Except for some ancient SCSI drivers nvme.device is very likely the first AmigaOS 4.x device driver using a command queue (sg2's drivers don't, I don't know anything about the Sam460, X1000 and X5000 SATA drivers).
The AmigaOS 4.x file systems were optimised for device drivers only supporting a single transfer at a time and have to be changed to benefit from device drivers with command queuing.

@joergQuote:

Interesting. AEON have built a replacement Copy command in the Enhancer pack, do you know if it incorporates what you have suggested?

@geennaamQuote:
Do you mean the filesystem itself, or how well AmigaOS can handle that filesystem? In Linux I can get over 1GB/s speed with the very same NTFS partition, so the limitation seems to be only on the Amiga side.

@joergQuote:
I was simply using the same method as @geennaam to get results comparable to his ones, nothing more. Those values I gave are for the default buffer size (128K), but did not get significantly better results with e.g. 512K or 1024K. How large SHOULD the buffer be to work optimally with a 1GB file?

@Rolar

The filesystem itself. Apparently the Amiga implementation is slow. Do you manage 1GB on the X5000 with Linux? Or on a Pc?

@daveywQuote:
As said, it was exactly that enhancer version I used for testing, and I think also @geennaam used it as the original 'Copy' does not have the 'SPEED' option.

@Rolar
Quote:geennaam is using 16 MB, but I don't know if he is using the AmigaOS or the Enhancer C:Copy.

@geennaamQuote:
Naturally on the X5000 . Please see details here:
https://forum.hyperion-entertainment.c ... wtopic.php?p=56906#p56906

@Rolar
You are using 10MB/100MB/1GB reads on Linux and compare them with 128KB ones (which are additionally twice as slow since you don't just use reads but copies from/to RAM: instead) on AmigaOS? Seriously?

To compare the Linux results from the Hyperion forum you'd have to use something likeinstead.

@joergQuote:
I tested now with 16MB buffer but got actually lower speed (75 MB/s) than with 128K (84 MB/s).

AmigaOS Copy does not have the 'SPEED' option.

@joergQuote:
I think you are now too severe towards an old man... I am not a professional computer expert nor a programmer. I thought the 1 GB filesize used by geenam would be comparable to the sample size used in 'Disks' tool, not the buffer size. Forgive my ignorance...

Quote:
Thanks! It is always best to give a simple and clear recipe how to do things right, instead of blaming. I will try that later...

@Rolar

sailor published SCSISpeed results in https://www.amigans.net/modules/newbb/ ... id=138777#forumpost138777

Only 200 MB/s, but I guess he used the default buffer sizes of SCSISpeed, which are extremely small. It's a tool from 1989 after all. It was implemented by an AmigaOS developer and even after nearly 35 years it's still an usable tool, but on current hardware only if you use much larger buffer sizes than the 512 Bytes(!) to 256KB defaults with the BUF1-BUF4 arguments.

@Rolar

No I use the OS4 copy command. And I do not use a SPEED option but the BUF option.

Can I create and format a Fat or Ntfs partition with aos4? Or do have to do so on another OS?

@geennaamQuote:
But how do you measure the transfer time...? At least the v. 53.6 Copy does not show it.

Quote:
Yes, you can do it with AOS4. In Mediatoolbox choose the 'type:' "Custom file system" and then input the 'identifier:' " 0x4E544653" (NTFS) or "0x4D534400" (FAT). Also exFAT ("0x45584641") should be available but have not tested it.

After rebooting the partitions should be visible on WB and can be formated.