Hi Kevin, I have a small correction for you because it was bothering me and would not let me sleep. I have no idea what went wrong there. You were absolutely right. If we align it 100% according to your specifications, a mount is indeed possible, regardless of the filesystem. However, as you also mentioned, we are light years away from iSCSI performance with this. Read speeds are around 30 MiB/s and write speeds are around 26 MiB/s. So these iSCSI speeds are roughly 20x faster than USB 1.1, at least that is something, but still slower than USB 2.0. That is definitely not even a start ;) Best regards, Torsten

Hi Kevin, thank you for the detailed reply. I think we need to separate Apple Silicon from Intel. On Apple Silicon, I agree with you. We tried many configurations while trying to make filesystem mounting work with the DEXT alone. Those settings were largely experimental. As long as a filesystem mount or subsequent I/O can trigger a kernel panic, further iSCSI tuning makes little sense. A reliable filesystem mount has to come first. On Intel, I disagree that the current implementation is not working as intended. Our initiator mounts filesystems and has passed byte-exact data integrity and memory-pressure tests without EIO or kernel panics. The current benchmark reaches about 16 Gbit/s. We could pursue more throughput, but the extra CPU load would hurt other work on the Mac. For Intel NAS use, this is a balance we’re happy with. When I used the word “header,” I meant the extra room we observed at the Intel transfer boundary inside the kernel, not additional filesystem I/O generated by the UBC. We did not measure or trace precisely where that margin comes from, since we cannot change that kernel behavior. Possible contributors include page alignment and padding, I/O mapping constraints, network hardware alignment, or bookkeeping associated with mbufs and memory descriptors. Ignoring the margin can cause errors or a sharp drop in throughput, so our Intel configuration accounts for it. In summary: “We don’t know what it is, but we accept it.” ;) Anyway, here’s my proposed deal: If you and your team can help make filesystem mounting and subsequent I/O reliable through the DEXT alone on Apple Silicon, without kernel panics, we’ll take care of getting the iSCSI side right. My personal goal is 105 Gbit/s. Our quick-and-dirty KEXT-assisted prototype already reached 81 Gbit/s in the RAW benchmark, so I’m curious to see what a reliable DEXT-only implementation can achieve. Then we can happily argue about geometry again. ;) Please keep us posted. As long as a matching KDK is available for the macOS build, we’d be happy to help you and your team at any time. Best greetings, Torsten

Hi Kevin, we have to accept the “no” regarding KEXTs, but at the moment there is no viable path forward for iSCSI on Apple Silicon. After a brief internal discussion, we have decided to halt development and take it off the table until this works without KEXT. Personally, I don’t see a way forward for at least the next six to nine months, so further development makes no sense at this point. Even the iSCSI mathematics involved are completely different with and without a KEXT. Nevertheless, thank you very much for your incredible support! Best greetings!! Torsten

Hi Kevin, This is a little difficult at the moment because we cannot take any measurements on the Apple Silicon machine until the end of October. My colleague is currently on vacation in Brazil, visiting his in-laws. However, I’ll try to reconstruct what happened from memory. We used exactly the values you suggested. This resulted in extremely slow performance, and only RAW access worked. Mounting the filesystem was not possible. Yes, we tried the 16 KiB configuration, but that did not get us any further. If it helps, I can send you a complete log showing exactly what happens, where, how, and when, but that will take a few days. There is also the maximum total read/write transfer size to consider. Explaining this in detail here in the forum would mean giving away a technical advantage, so if anything is unclear, please ask me to clarify. When the data passes through the kernel, Apple adds a header. It is small, but accounting for it is extremely important. Interestingly, it differs between Intel and Apple Silicon. So yes, we can use the system values, but doing so produces large numbers of errors or, depending on the configuration, read/write or completion errors. The kernel also frequently logs EIO errors. There is no panic, but we then see SCSI errors—sometimes just a few, sometimes a large number. There is no additional logging of this except at one specific point when an error occurs. That is why simply choosing 1 MiB or 2 MiB does not work reliably. Some additional calculations are necessary to make this work correctly and consistently. Does this help for now? Best greetings, Torsten

Hi Kevin, just for clarification: I'm sorry, but that isn't going to happen. We're very unlikely to grant them at all today, and we've never granted them for testing purposes. Does this mean we can get the KEXT entitlement for a rollout until everything is done on your end? If YES and that were possible, that would be awesome. Naturally, we wouldn't just use it for testing then and we would only need it until everything is fixed. Best greetings, Torsten

Hi Kevin, thanks a lot for the quick view and answer. You went through all the Feedback reports remarkably quickly. Huge respect for that. Q1. Why did you choose a 4KiB maximum and 16KiB alignment for FB25095303? What were you trying to establish? We first tried the 16KiB maximum, 16KiB alignment and one-segment configuration you had suggested. That led us to the 4KiB test. When nothing makes sense, I sometimes like to try something seemingly pointless to confirm the pointlessness. So we stepped back into abstraction and asked where the “famous” single difference between Intel and Apple Silicon was. We focused on 4KiB versus 16KiB and tried the Intel settings on Apple Silicon. The M5 kernel’s 16KiB page size was the one thing we could not change. It was a direct comparison. In the 4KiB diagnostic build, the host-facing maximum read and write byte counts and maximum segment byte counts were also 4KiB. Its captured IORegistry reports two HBA segments. Q2. What happened in the 16KiB/16KiB test? Which filesystem did you format or mount and what exactly failed? Only RAW access worked. Formatting and mounting preformatted LUNs began but then nothing happened. There was no completed filesystem mount, no error and no panic. We did not investigate where the operations stopped. In separate tests, even exFAT caused a panic. That led us to add strict read-only mounting to the initiator. With that enabled, all the filesystems we tried mounted. Writes and formatting were rejected, including format commands issued from the command line. Q3. How did you measure approximately 0.08 Gbit/s? We used RAW writes, reads and byte by byte verification. The data matched and we saw no EIO or panic during the 16KiB/16KiB test. We were primarily checking for those failures. At roughly 0.08 Gbit/s, we quickly dropped that configuration. I expected your answer about the KEXT entitlement and was pretty sure from the start. However, Micha from my team thought I should ask you anyway. Well, I won that bet. ;) The KEXT was an experiment to answer one question: can we avoid the panic at all? With it in place, we could read, write and verify without errors or panics. Even hours-long write or read tests completed without a single EIO. We have not yet run a dedicated test under heavy memory pressure to stress DMA and memory. At this stage, our main question was whether the approach worked at all. The results show us that we are moving in the right direction, but I agree with you that this is a useful proof rather than a solution. From my point of view, needing a KEXT just to get a DEXT working is almost an oxymoron. That is also why we included the KEXT source with the Feedback reports. It is only meant to show how we worked around the panic in a “quick & dirty” way. Perhaps it will be useful to your team as well. Best greetings!! Torsten

Hi Kevin, When I told my wife about your explanation that we couldn't bypass this in the DEXT, she reminded me of something I'd managed to forget. Back in 2001 I had a pretty heated argument with Microsoft about Active Directory and domain controllers because they insisted something couldn't be done. I proved otherwise. Three weeks later I got a letter from Microsoft and ended up working for them for almost two years. So of course we tried everything we could think of within the DEXT. When that didn't work, we tried a companion KEXT and finally got the filesystem path running. I don't believe in "can't be done". There's always a way. Don't worry, Kevin. A repeat of that story would be really funny, but I'm way too old for that shit these days. ;) Okay, now let's get to the facts. Your sentence about “wrong geometry” stuck with me. That was the magic sentence. So we started from scratch and ignored all the limits you suggested. Nothing personal. We thought it was worth a try. On Intel, we traced 32 RAW reads, half with ordinary buffers and half with reverse-order shared-page aliases. All returned the expected data. Each produced one full-length DMA segment, and AppleVTD::iovmMapMemory succeeded in the SCSI path. Separately, we ran your adjacent-mapping test against a NAS LUN. All four writes under memory pressure completed with full uncached readback and zero byte mismatches. We did not trace how the kernel divided those particular writes into DEXT requests. On the M5, we also tried a 16KiB maximum with 16KiB alignment, matching its page size. The other DMA parameters remained at 64 address bits and Host64. RAW I/O worked at about 0.08 Gbit/s. Formatting a LUN did not produce a usable filesystem, and mounting an already formatted LUN produced no usable volume. The mount attempt caused no panic. In the Intel configurations we tested, the iSCSI path kept working without EIO or kernel panic. In a separate four-day continuous test, we observed no errors. The local DEXT benchmark reached around 21 Gbit/s, which is enough for the SOHO and NAS use case we have in mind. We had hoped to support Intel Macs back to Big Sur, but the framework made Ventura our starting point. We built separate initiators for the supported Mac platforms from macOS 13 onward because of framework and SDK differences. Even the real nerds among my friends are happy with 16 Gbit/s infrastructure in their basements, and they're impressed with the performance. On Apple Silicon, the DEXT benchmark reaches roughly three times the Intel result. But for filesystem workloads, we currently need the companion KEXT. I'd therefore like to ask you to look at these Feedback reports: FB23814092 (with an addendum) FB25095286 FB25095293 FB25095303 FB25095318 You asked us not to say or imply anything about Apple's plans or a possible fix. Of course I'll respect that. I won't discuss it publicly. To keep testing, a temporary KEXT signing entitlement would be extremely helpful. We included source for a working KEXT revision with the Feedback reports so you can see that it does not handle iSCSI. It prepares block buffers for the DEXT and the iSCSI protocol and networking remain in userspace. I know KEXTs are being phased out. If we can get the entitlement, great. If not, we'll wait. That would be a shame, but I'm not going to make a drama out of it. Just a notice for you: We'll keep the software in beta until the questions raised in the Feedback reports are resolved. The KEXT is a workaround while those questions remain open. Once they're resolved, we can decide when a release makes sense in light of your guidance. There's no pressure from my side; the current setup lets us keep working. The screenshots show it in action. Thank you again for the Null Driver. As promised, it's now immortalized in the app. ;) We've also run multi-day stress tests across a wide range of configurations, and the results so far have been positive. Not even one EIO!!! Awesome!!! We're continuing to refine and optimize the initiator's iSCSI handling for clean, reliable communication with target servers. That's where things stand today. I'm curious what you think, especially whether Apple could support us with the KEXT. Best regards, Torsten

Hi Kevin, just a brief status update for now. Over the past week, I obtained a few used MacBook Pros (Intel) for testing. On Intel Macs running Big Sur or later, the SCSI path works without the limits you suggested. Peak throughput remains just near 20 Gbit/s. On the M5, we’re currently seeing 62 Gbit/s though with a workaround: for filesystem workloads, the DEXT currently needs a companion KEXT. I know, it's cheating - but hey, the combination works. ;) No EIO or kernel panic. I’ll send more details next week when the KEXT is running on a "none developer device". At the moment, I can’t submit the KEXT signing request because Apple’s request page repeatedly returns an NGINX error. Could you help with the request or should I try again tomorrow? Perhaps the server is only temporarily unavailable. Best & have a nice weekend!!! Torsten

Hi Kevin, You were right about the DMA issue, but also slightly wrong about how far we could get with it. No worries, only slightly. ;) Intel has made the story a little more entertaining. There is something that looks suspiciously like a working bypass, which we initially summed up in two words: “ignoring facts.” Your recommendation is clear: keep maxTransferSize at one page. That is the supported way to avoid depending on favourable mapping conditions. Our Intel configuration goes beyond that limit. Reducing it to one page would cost us the performance we are currently seeing. The interesting part is what happens before the request reaches our DEXT. On Intel, we traced the family’s DMA preparation through AppleVTD::iovmMapMemory, followed by a single DMA segment covering the full request. Once that succeeds, we access the CPU-visible buffer through the descriptor API. We are not treating a device DMA address as a CPU pointer. So the original dependency is still there. Intel’s mapping path lets these requests through anyway. Call that a feature, a loophole or Intel being rather forgiving. Strictly speaking, the Intel path gets this wrong, but its laxness is currently a stroke of luck for us. It does not make Intel the better CPU or Apple Silicon the worse one. The framework still expects a device-style DMA mapping for a controller whose data movement is done by the CPU. Tadaaa!!! As usual: Do it wrong to get it right. ;) That is what I meant by “ignoring facts” at the start. Yes, the underlying issue exists on Intel too, but it has had no observable effect in our tests. I probably don’t need to tell you that relying on this isn’t exactly a brilliant long-term strategy, but in our case it has paid off so far. We have now run the Intel implementation for several days without observing write, read or verify errors. With those results, I think we can live with this temporarily, while keeping the software explicitly in beta until the framework issue is fixed. We still account for hw.pagesize internally; that is separate from limiting maxTransferSize to one page. Page alignment is not required by our tested configuration. We could explain the broader behaviour, but this is a public forum where everyone can read along. We’d quite like to keep a little of our technical head start. ;) We can share the broader test results, though. Both Intel and M5 completed our RAW I/O tests successfully. These covered for example: Page reordering: A-B → B-A. Page duplication: A-B → A-A. Physical memory fragmentation. Virtually contiguous buffers with non-contiguous physical backing. Misaligned buffers and transfers crossing page boundaries. Randomized prefaulting combined with memory churn. These were RAW tests, not file operations through a mounted filesystem. We tried pretty much everything and really tortured the machines, but nothing killed the kernel. We have not observed read/write/verify errors in the completed runs either. We are keeping these results separate from your UBC explanation. Successful RAW runs do not establish that the mounted-filesystem path will behave the same way, nor do they invalidate your warning about memory pressure and allocation history. The M5 shows exactly that. Its kernel panicked only when we switched from RAW access to the OS filesystem by formatting or mounting the target. No matter what we tried, even an already formatted target refused to mount, which blocks all filesystem tests there for now. So this is where the DMA address issue becomes visible: only in the filesystem path and only on the M5. RAW-only support would technically be an option, but I suspect “you can access your storage, just please don’t mount it” would be a slightly harder sell to users. ;) Seriously, though: Another big thank you to you and the kernel team!!!! From what our software and measurements are showing us, we sometimes think you give your own kernel too little credit. We appreciate how quickly you have helped us investigate this and that the storage team is taking it seriously. I’m very curious to see what we can get out of this driver once it no longer has to work with one hand tied behind its back. With all that explained, here is what we would like to do, if you’re comfortable with it: start a public beta for Intel Macs. The Intel implementation is now running at a little over 20 Gbit/s and works well enough to be useful. Reducing the transfer limit to one page would cost us that performance. We understand why you recommend it. Our successful tests do not remove the uncertainty you described. We would make that limitation clear in the beta notes and keep the software explicitly in beta until your fix is released, while gathering feedback from more Intel configurations and continuing our work on Apple Silicon. I know this goes against your recommendation and Apple’s, but I think it’s a practical compromise we could both be happy with. And no worries if you explicitly advise against it. Given your role at DTS, I’d completely understand and respect that position. Best greetings, Torsten

Hi Kevin, Thank you for the straight answer and for taking this seriously. I won't pretend that was an easy message to read. This is pretty devastating news for us and puts our release plans for this year in serious doubt. We absolutely take your warning seriously. To answer your question directly: the 1 MiB measurements came from pread and pwrite against /dev/rdisk2, with F_NOCACHE enabled using ordinary page-aligned buffers. They did not come from VFS file I/O or the buffered /dev/disk2 node. We have also completed multiple continuous 400 GB RAW write, read and verification runs all cleanly. These were not just short throughput measurements. Given that, does your explanation about the UBC incidentally providing physically contiguous pages also apply to this RAW path? Or could we be looking at a different set of conditions there? I want to make sure we distinguish the paths correctly and understand exactly what could trigger the failure despite those successful runs. Our current SCSI implementation already includes the shared-memory ring, bundled task handling and parallel copy processing. It accepts large tasks, and our RAW benchmarks exceed 20 Gbit/s. The concern now is whether we can reliably ship that configuration on current macOS. Is there any supported workaround for the DMA preparation issue? As we understand it, the kernel checks the DMA segment layout before handing the task to our DEXT. If that check rejects the request, allocating a different buffer inside our task handler comes too late. Could an existing DMA or HBA configuration make the kernel provide a suitable physically contiguous bounce buffer before that check? Or is there another supported mechanism that removes the dependency on the original buffer's physical layout? We can accept an extra copy or a throughput penalty if it gives us a reliable native SCSI path. Our IODMACommand::PerformOperation experiment eliminated the mapping faults in the DEXT, but we understand that this does not remove the earlier DMA preparation. If there is no supported workaround, do we need the kernel fix you discussed with the team before shipping this large-I/O configuration? And regarding that software-I/O switch: if you can share even a rough estimate, are we talking about weeks, months or potentially years? I know you cannot promise a release date, and I won't hold you to an estimate. We just need some sense of the timeframe to plan around. Even a temporary, supported workaround would solve a huge number of problems for us. Thanks again for sticking with this and discussing it with the team. This is really difficult news, but we appreciate your honesty and your help in finding a way forward. Best regards, Torsten

Hi Kevin, Thanks, that helps. Two questions came to mind: 1. Larger transfers and lock contention We’re already seeing actual 1 MiB SCSI tasks arrive at the DEXT. Would you expect the planned larger-I/O fix to help with submission/completion contention at that size too, or would the main benefit be for workloads still split into page-sized tasks? 2. SuperPages and a software SCSI bridge This bit caught our attention: My guess is that using larger memory descriptors may change the faulting statistics a bit, but I don’t think the overall impact will be dramatic. That made us wonder whether SuperPages could be useful as part of a lightweight software SCSI bridge. Since they already exist, could there be a supported way to put them to work for iSCSI with efficient CPU access and concurrent transfers? Just an idea, but it looks promising to us if the framework could make them straightforward to use in this context. We’d certainly like to have that option. Freedom for iSCSI! Give us the SuperPages! If we get that bridge, you’ll never hear from us again. Well, if it works. Promise. 😉 Seriously though, our small test worked with one SuperPage in flight and we verified the data byte for byte (QD1). When we tried to scale up, allocation failed before I/O started. Could this become a practical option for concurrent iSCSI transfers? Or is there something about SuperPages or the SCSI path that makes them unsuitable here? We’d appreciate your take before pursuing the idea further. Cheers and thanks again! Torsten

Hi Kevin! We finally broke through 20 Gbit/s and only at that speed did another problem become visible. It is not a blocker for us, but we hope you have a solution for it. Our DEXT moves each task's data between the IOBufferMemoryDescriptor from UserGetDataBuffer and its own shared ring. Tasks are 1 MiB. Both public API paths for that copy are expensive for us, though in different ways. A: map the descriptor. GetAddressRange, then memcpy. Every 1 MiB task causes 256 page faults in the DEXT (PROC_PIDTASKINFO pti_faults; the app takes almost none and the peer takes none, no COW faults, no pageins). 2047 KiB tasks cause 514. DEXT CPU per task: 0.62 ms user + 1.34 ms system (READ), 0.47 + 1.00 ms (WRITE). About 2 700 tasks/s with four copy queues, and CPU_Speed_Limit drops to around 60 during the run. B: kernel copy, no mapping. One IODMACommand per copy queue, Create(this, 0, {options 0, maxAddressBits 64}, &cmd). Per part: PrepareForDMA(0, hostDescriptor, offset, length, &flags, &count, segments), PerformOperation (OptionWrite for READ data, OptionRead for WRITE data, dmaOffset 0, length, ringOffset, ringDescriptor), CompleteDMA(0). All calls succeed, 582 435 parts, zero error returns, READ data verified (the test target discards WRITE data). The faults are gone, but PerformOperation takes about 1.375 ms of elapsed time per 1 MiB (prepare 10 µs, complete 6 µs) and DEXT CPU per task rises to 0.18 ms user + 3.29 ms system. Median READ at QD8 fell from 22.06 to 15.01 Gbit/s, WRITE from 20.39 to 15.84. That leaves us with three questions for you: Is there a supported way to access the task data without faulting every newly mapped page or copying through an intermediate buffer? For example a mapping that is populated up front (kIOMapPrefault is not among the public CreateMapping options and GetAddressRange takes no options). Is PerformOperation intended for this use case? Its implementation in the KDK appears to allocate an intermediate buffer and copy through it. Is there a way to copy between the two descriptors without that buffer? This looks like the same gap as in our already reported descriptor issues: every task still materializes a framework owned per task descriptor. Path A faults once per page of it, path B copies through an intermediate buffer. Does the planned software I/O path (task scoped, CPU accessible, multi page descriptor without hardware DMA preparation) cover this? If so, this measurement may be useful as the performance side of those reports. Thanks, Torsten

Hi Kevin, We seem to have found another little problem in the kernel. It's not a showstopper but it would be good to get this fixed. We've been digging further into the latency spikes and traced one of the long stalls into the kernel submission path. I'd like to get your take before opening a Feedback report. Perhaps there's something we can do on the DEXT side that we're missing. Our iSCSI initiator is running on macOS against a loopback null target. The controller reports a maximum of 256 parallel tasks. We're using synchronous 1-MiB pread calls from multiple threads. QD here is the number of outstanding host requests, not the number of commands active on the wire. At QD1 to QD64, the latency already looked a bit off, but it wasn't obvious what was happening. We then deliberately pushed the test to QD512 and QD1024. That's when the long stalls really stood out and we could follow the affected thread into the kernel. Above the task-pool depth, one raw read doesn't return for roughly the entire load run, while the other threads keep completing thousands of requests: Host QD Requested load duration Longest raw read 256 10 s 203 ms 512 10 s 10,161 ms 512 20 s 20,271 ms 1024 10 s 10,504 ms 1024 20 s 20,507 ms Even at QD256, the longest read is "only" 203 ms, so it doesn't look nearly as dramatic at first glance. With workloads involving millions of block I/Os, though, even shorter recurring delays can matter. It was only at QD512 and QD1024 that the sustained, multi-second stall became unmistakable. We recorded the slow worker's OS thread ID and the exact start/end times of that read, then matched them to kernel stackshots. At QD1024/10 s, all 104 samples of that thread have this chain (leaving out the intermediate frames): pread IOSCSIProtocolServices::ExecuteCommand IOSCSIProtocolServices::SendSCSITasksFromQueue IOSCSIParallelInterfaceDevice::SendSCSICommand IOSCSIParallelInterfaceController::GetSCSIParallelTask IOCommandPool::getCommand IOCommandPool::gatedGetCommand The sampled PC in gatedGetCommand is the return address right after commandSleep. The 20-second runs show the same queue-draining path throughout the captured samples, mostly waiting for a task from the pool. We also checked the disassembly of the installed Kernel Collection, with the SCSI images matched to the KDK by UUID. ExecuteCommand calls the shared queue drainer inline. That loop keeps picking up more queued tasks. SendSCSICommand can wait for a free parallel task when called outside the workloop thread. Our reading is that one submitting thread ends up draining the queue for everyone else and gets held there as other callers keep adding work. Doubling the load duration from 10 to 20 seconds roughly doubles that read's latency too, which looks more like starvation under sustained load than a fixed timeout. One detail we haven't captured yet is exactly when that read's own SCSI task completes. Does that reading make sense to you or have we missed something? Is there a supported way to handle submission or completion in the DEXT that avoids holding up one caller like this while keeping the I/O concurrent? Or should I open a Feedback report? Best regards, Torsten

Hi Kevin, We’re already using UserProcessBundledParallelTasks, with no single-task callbacks. We’re just not getting as much batching out of it as we’d like. In the latest run with roughly 1024 KiB I/O and host QD1 to 128, we counted about 3.21 million bundled callbacks for 3.26 million block requests: roughly 1.016 block requests per callback. That’s from the whole-run counters rather than a slot-count histogram. We also looked at the kernel path. Tasks go through serial preparation, including DMA preparation, before entering the batching queue. The delayed dispatch uses a fixed 10us interval. For now, though, we can live with it. Average RAW I/O latency at QD64 is around 20 to 30 ms. A bit annoying, but I guess it's OK. ;) We’d rather wait for the DMA fix before spending more time on batching. Being able to use larger I/O sizes again means fewer tasks for the same amount of data. That could reduce the overhead enough that the limited batching no longer matters much for us, even if the batches themselves stay small. Once that fix is available, we’ll take another look and see whether any further changes are needed at all. If they are, being able to adjust the 10us interval would be helpful. We have one or two other ideas as well, but we need to wait for the DMA fix before deciding whether they’re needed at all. Best regards, Torsten

Hi Kevin, after a short vacation last week, here is a first small update for you, just so you don't think I have forgotten about you. We are still tuning, but here are a few early numbers already (Intel based). Well, if 1 Gbit already surprises you, then I do not know what you will say about these numbers. And a big compliment to the entire kernel developer team here, because it shows there is not just work behind this but also an enormous amount of know-how. Calibration and warmup: Data measurement (100-iteration loop): I am not sure how you would rate these, but to me they look good enough to keep. We also made a decision: the NULL driver goes into the initiator itself, as a built-in benchmark. That way the user can see right away whether something is the initiator or the network configuration. Thanks again for the pointer at exactly the right spot. Based on your 1 Gbit remark, the numbers should come as a surprise. That is also why the 'nDEXT Benchmark' will stay in the app. Sure, we can claim a lot here, but some people will surely want to verify it. They are welcome to and a matching measurement script is no big deal. I think any AI can put one together in two minutes. All in all we are happy with where this stands. The one thing we still want to get under control is the extreme outliers (compare High vs Low). As a side note, we have already broken the 20 Gbit/s mark, although it hits the CPU hard. In short, the DEXT can hold its own. Once this runs stably on Intel, we will move to the M5 for testing. Those still have delivery delays but they should (supposedly) arrive by the end of this week. I am curious. Best, Torsten