@Georg UNIT_VBLANK isn't different to UNIT_ECLOCK anymore since that's not even possible (except for the A1200 and A4000 versions of AmigaOS 4.x maybe): timer.device has to work before the gfx card drivers are started and get the monitor frequencies. All timer.device units are probably based on the same CPU timers.
@geennaam Found the problem in SCSISpeed: It's limited to about 200 MB/s (2^32 bytes / 20 seconds) because of the ULONG count in SpeedTest(). Changing ULONG to uint64 count should fix it. Maybe updating the calculations and printing the MB/s is required as well. Using "SCSISpeed MINTIME=1 ...", instead of the default 20 seconds, should work as well, without changing the sources.
Using ReadEClock() you get higher precision than "just" microseconds, however additional to converting it to (micro)seconds you have to check for overflows. GetUpTime() results can't overflow, ReadEClock() results do. If you need even more precision than EClock you'd have to use performancemonitor.resource, which can measure CPU cycles.
In the meantime I have created my own benchmark. It's rudimentary for now but I intend to expand it with a graphical printout like those nice PC tools.
Anyways, here's the result:
Samsung SSD Connected to the X5000 internal SATA port. At 32MByte and onwards it starts to divide the transfer in chunks according to the output on the debug terminal
SSDBenchmark V0.1
device: p50x0sata.device,1
Read size: 4096 bytes
Result: 24 Mbyte/s
Read size: 8192 bytes
Result: 31 Mbyte/s
Read size: 16384 bytes
Result: 57 Mbyte/s
Read size: 32768 bytes
Result: 90 Mbyte/s
Read size: 65536 bytes
Result: 94 Mbyte/s
Read size: 131072 bytes
Result: 176 Mbyte/s
Read size: 262144 bytes
Result: 217 Mbyte/s
Read size: 524288 bytes
Result: 242 Mbyte/s
Read size: 1048576 bytes
Result: 249 Mbyte/s
Read size: 2097152 bytes
Result: 248 Mbyte/s
Read size: 4194304 bytes
Result: 247 Mbyte/s
Read size: 8388608 bytes
Result: 247 Mbyte/s
Read size: 16777216 bytes
Result: 247 Mbyte/s
Read size: 33554432 bytes
Result: 235 Mbyte/s
Read size: 67108864 bytes
Result: 112 Mbyte/s
Read size: 134217728 bytes
Result: 112 Mbyte/s
Samsung NVMe SSD: Starting at 16kb I have to get the physical page addresses of the read buffer to create a " Physical Region Page" list and feed it to the NVMe controller. Getting the physical address of a page in supervisor mode creates a lot of overhead as can be seen from the transfer speed. That's why pipelining of commands is so important as can be seen for the larger transfers. In the future I want to rewrite that part of the driver to use Scatter Gather lists. If the buffer isn't fragmented then this should reduce overhead severely.
In the meantime I have created my own benchmark. It's rudimentary for now but I intend to expand it with a graphical printout like those nice PC tools.
Great! Are you going to publish it, or is it only for your own use?
Getting the physical address of a page in supervisor mode creates a lot of overhead as can be seen from the transfer speed. That's why pipelining of commands is so important as can be seen for the larger transfers. In the future I want to rewrite that part of the driver to use Scatter Gather lists. If the buffer isn't fragmented then this should reduce overhead severely.
For a start use something like
uint32 flags = 0;
if (write) flags = DMAF_ReadFromRAM;
if (1 == IExec->StartDMA(buffer, size, flags))
{
// not fragmented
struct DMAEntry dmaentry;
IExec->GetDMAList(buffer, size, flags, &dmaentry);
// physical address of the first page is dmaentry.PhysicalAddress
// 2nd page dmaentry.PhysicalAddress + PageSize
// etc.
} else {
// fragmented, use current code
}
IExec->EndDMA(buffer, size, flags);
If you want to cheat in your benchmark tool allocate the memory with
For now it is a tool to profile my code and see how I can ootimese the speed. But I do intent to release it as a standalone tool some day.
One of the things that I've learned is that a DoIO() with CMD_READ (32bit) is executed much faster is than NSCMD_TD_READ64 (64bit). No idea why this would make such a difference for OS4.
One of the things that I've learned is that a DoIO() with CMD_READ (32bit) is executed much faster is than NSCMD_TD_READ64 (64bit). No idea why this would make such a difference for OS4.
There should be no difference at all in the exec.library functions (DoIO(), SendIO(), BeginIO(), WaitIO(), CheckIO(), AbortIO()), and only a very tiny one in applications and device drivers (uint32 lba = io_Offset / sector_size vs. uint64 lba = (((uint64)io_Actual << 32) | io_Offset) / sector_size).
Try if adding NONSD to the SetPatch arguments in S:Startup-Sequence makes a difference, if yes something is wrong in your driver not supporting some NSD parts correctly.
In my driver there is no difference in how I handle both commands. It always handles the address as 64bit. I just additionally zero the upper address for CMD_READ to make sure that there's no garbage which could Lead to a wrong address. I also see no difference in execution time within my driver. This looks OS4 related.
I've seen the sources and I can assure you that there is no difference at all between CMD_READ and NSCMD_TD_READ64, or any other command, in the exec.library functions. However, the SetPatch/NSDPatch replacement functions of the exec IO functions are something completely different, and I never checked them. I would be extremely bad if it's still required to add a "ISNSD" config line for nvme.device in DEVS:NSDPatch.cfg since that would mean it still assumes that all device drivers are broken, but OTOH that wouldn't surprise me.
I have currently quite peculiar problem with my NVMe drive... I have on it several EXT4 partitions which I use with Linux, and a large NTFS partition which can be accessed also from AmigaOS. If I hide the icon of that partition from WB screen using the "Workbench" prefs, booting goes without problems. But if I do not hide it, booting usually stops before WB is fully loaded (only a grey screen and the white menubar is shown) and the whole system freezes. Rebooting helps only occasionally.
No, I do not know how hiding icons affect amigaos. Maybe @Joerg knows what could be the issue.
This doesn't happen for amiga filesystems. So one thing I could think of is that the NTFS-3G/Filesysbox combo might not have been implemented with fixed storage in mind. And removable storage like USB drives might be loaded and mounted after all dependancies of NTFS-3G/Filesysbox are available.
No, I do not know how hiding icons affect amigaos. Maybe @Joerg knows what could be the issue.
When I tested this issue further, I noticed that hangups happen also when the icon is hidden, but with clearly lower frequency. The NTFS partition is of course still mounted. But if I disable 'nvme'device' totally, the booting problems seem to dissappear completely.
Quote:
This doesn't happen for amiga filesystems. So one thing I could think of is that the NTFS-3G/Filesysbox combo might not have been implemented with fixed storage in mind. And removable storage like USB drives might be loaded and mounted after all dependancies of NTFS-3G/Filesysbox are available.
Do you know whether it is somehow possible to disable the mounting of a certain partition during bootup?
When I tested this issue further, I noticed that hangups happen also when the icon is hidden, but with clearly lower frequency. The NTFS partition is of course still mounted. But if I disable 'nvme'device' totally, the booting problems seem to dissappear completely.
Then it definitly seems timing related. What you can do is remove nvme.device from the kicklayout and mount the partitions with sys:System/Mounter instead. Make sure that you change the device in the tooltype to nvme.device.
Quote:
Do you know whether it is somehow possible to disable the mounting of a certain partition during bootup?
No idea. I don't mount myself but hand it over to the mounter.library. However, there might be a configuration file somewhere.
Then it definitly seems timing related. What you can do is remove nvme.device from the kicklayout and mount the partitions with sys:System/Mounter instead. Make sure that you change the device in the tooltype to nvme.device.
Mounter cannot use a GPT formated disk. The 'MassStorage' commodity can, but it is somewhat tedious to use as you have to use the commodity exchange to open it. Unless there is some way to use it from cli...? Then I coud make script for mounting nvme partitions.
No, I do not know how hiding icons affect amigaos. Maybe @Joerg knows what could be the issue.
I don't know anything about mounter.library nor how FUSE/FileSysBox file systems work, but there used to be a problem with some file systems if the partitions are mounted without ACTIVATE, i.e. the file system isn't started immediately but only on first access of DHx:. In this case the first access is very likely the one done by the Workbench trying to load the disk.info icon file.
I'm testing now an A-Data SX8200 PRO 512 GB nvme disk in my X5000. I cannot get the nvme.device to work wth it. If I have it activated in Kicklayout, booting halts always after kickstartmodules are loaded (just like when there is no nvme disk installed at all).
I tested the A-Data first totally unformatted, then GPT fromatted but without partitions, and finally with partitions (EXT4 and NTFS) on it, but no difference. From Linux it works normally, so the disk itself (and the Axagon PCIe x4 adapter) seems to be ok.
Can you see any reason for this, and possible a fix...? This ADATA model has a DDR4 cache on it. I tested earlier an A-Data XPG GAMMIX S11 Pro (without cache), and it seemed to work ok, as did the Kingston NV2 as I reported here earlier.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
