Live data from Hacker News

Viewing profile — emmericp

emmericp

HN member
Joined
Sun, Nov 19, 2017, 6:07 AM UTC
HN karma
393
Public activity
70 items

About emmericp

Artisanal handcrafted network card drivers: https://github.com/emmericp/ixy

Recent public activity

  1. comment
    Comment #44549160

    (Native German speaker here), it's a very rare use of the word "free" and usually only used in fixed terms like "Freibier", it wouldn't even work for other drinks, e.g., you can't …

  2. comment
    Comment #43810813

    I'm surprised that the recent advances in applying typography to engineering problems [1, 2] are not published at SIGBOVIK but are apparently going to a more serious journal. [1] h…

  3. comment
    Comment #40836794

    The time-travelling UB interpretation was popularized by this blog post about 10 years ago [1]. I'm not enough of a specification lawyer to say that this is definitely true, but th…

  4. comment
    Comment #40836675

    uIP (TCP/IP stack for tiny microcontrollers) is a another fun real-world example for these types of coroutines: https://github.com/adamdunkels/uip/blob/master/uip/lc-switch...

  5. comment
    Comment #37037495

    66% was drivers in 2019.

  6. comment
    Comment #32039534

    My aunt donated my grandpa‘s old slide rule there some time ago [0]. Crazy how far we came in just two generations. Fun to see this site show up on HN :) [0] https://sliderulemuseu…

  7. comment
    Comment #29936856

    Yes, you should publish it. Don't bother cleaning it up if you don't feel like it. No one will judge you for the code quality. Published terrible code is far better than unpublishe…

  8. comment
    Comment #28563480

    We wrote some experimental network drivers in high-level languages a few years ago and Java performed better than expected. Yeah, that's a very special and somewhat odd use case, b…

  9. comment
    Comment #27249821

    Most "new tech" is engineering, not science. If you want empiricism try academic papers instead of mailing lists ;) Some numbers: most critical bugs in the Linux kernel are due to …

  10. comment
    Comment #27202012

    The real root cause for all that flow director mess and core balancing is that there's a huge disconnect between how the hardware works and what the socket API offers by default. T…

  11. comment
    Comment #26760266

    Lesson 1: Never ever reboot multiple Ceph nodes without checking if Ceph is happy between reboots. This failure happened early during boot and this could have been handled with no …

  12. comment
    Comment #23044868

    The NIC can hash on IPs and UDP ports just fine, nothing to worry about here. Sure, there's the rare case of a connection moving to a different L3/4 flow identifier causing a cache…

  13. comment
    Comment #23044818

    The hardware selection and test setup is questionable, yeah. But downclocking the CPU is pretty standard for many benchmarks like that. Would have been better to evaluate the effec…

  14. comment
    Comment #23043951

    Isn't a large part of the performance gain from TSO offloading on transmit due to avoiding working with way too many skb's in the kernel? Shouldn't GSO for UDP with proper NIC supp…

  15. comment
    Comment #22935125

    > But enabling tcp timestamps in general case brings little benefit and wastes 12 bytes of each packet for basically no gain. I disagree; TCP timestamps are awesome. Linux enables …

  16. comment
    Comment #22415607

    There's only one level of TLBs in the IOMMU. And that's 64 entries. Yeah, I think the dTLB is only 64 entries on Intel CPUs as well, but there's a second larger layer behind that, …

  17. comment
    Comment #22414174

    Interesting, did you use huge pages? I think ~100k to 200k TSO "packets" per second should be doable with the IOMMU. But I guess it depends where the data is coming from. Could be …

  18. comment
    Comment #22413734

    A problem on the hardware side is that Intel's IOMMU TLB is tiny (64 entries), so using huge pages for all DMA-accessible memory is absolutely required to get a good performance ou…

  19. comment
    Comment #21737156

    Related: I ran some benchmarks for all GCs in OpenJDK 12 some time ago: https://github.com/ixy-languages/ixy-languages/blob/master/J... Epsilon tied on speed but lost to Shenandoah…

  20. comment
    Comment #21037470

    Not a game developer, but I used to write UI addons for World of Warcraft. WoW allows you to customize your UI heavily with these Lua plugins ("addons") and Lua is garbage collecte…

  21. comment
    Comment #20952156

    The Semaphore is only used during initialization, never in the critical path, see profiling results in the main repo

  22. comment
    Comment #20952037

    Yes, we do if we want to have an idiomatic interface for the application on top of the driver. Pull requests proving otherwise are welcome

  23. comment
    Comment #20950910

    Yes, we could write most of the critical part in C and it would probably be faster. But then it wouldn't be a Swift driver.

  24. comment
    Comment #20949645

    Java reaches 52% of C speed in the benchmark game ("fastest measurement at the largest workload" data set, geometric mean), we reach 38%. Seems like our implementation is within a …

  25. comment
    Comment #20949616

    PCIe bandwidth also decreases with increasing packet size as there's a lot of overhead per packet. Memory isn't used, it's all handled in cache, hitting main memory is super slow.