Posts made by Jacob Gallant

@george1421 Thanks george, that did the trick.

@george1421 Thanks, I’ll look into that. No need to provide the custom kernel info if that isn’t what I need.

@george1421 Sure, we had new ProBook 750 G8s arrive that we could boot with. Here’s where we stalled at: https://photos.app.goo.gl/EbG6kTro1eAJStR67

Tried all the latest kernels and had no luck.

Hi folks,

I’m trying to build a custom kernel based on the steps here, but when I get to the makefile steps I’m getting some error 127 stuff popping up. I’m well out of my depth here so I could be doing something completely wrong, just looking for some friendly advice. Screenshot:

https://photos.app.goo.gl/uJVA2YjcNBxW14hf8

Thanks!

I can report that both using the USB3 key method and enabling VMD worked for us as well. Great finds!

@sebastian-roth said in HP ProBook 640 G8 imaging extremely slowly:

@Dungody Thanks for the update and pictures! Definitely looks like you deploy to the NVMe driver. I still can’t see why a USB key plugged into the ProBook would make a difference. Though it sounds like it does.

In the picture I notice that you have partclone version 0.2.89. In FOG 1.5.9 we use the newer partclone 0.3.13. So I am wondering which version of FOG you use and if that is also playing a role here.

@Jacob-Gallant Would you want to give that a try as well?

I’d be happy to test this (and @diegotiranya storage controller settings) when I can, but we’ve been locked down due to COVID where I am so I can’t get back into the office in the near term. Looks like you have a few other testers now though! Glad I’m not the only one haha.

@sebastian-roth Thanks, I appreciate your efforts!

@sebastian-roth Thanks again Sebastian, here is the results of that command. Unfortunately we see the same network performance issues with this kernel.

https://photos.app.goo.gl/6Ur7aNkjF92MEKAi6

@sebastian-roth Here you are. https://photos.app.goo.gl/uJJKgG4PSPHY8kQJ6

@sebastian-roth Hey Sebastian, the mtu size was 1500 when I ran than command. Unfortunately when I used the patched kernel I received a “no network interfaces found” error, did I miss a step?

https://photos.app.goo.gl/ieBtBtrgCReWB8BU6

@sebastian-roth OK, totally understand. Just let me know! Thanks for everything Sebastian.

@sebastian-roth How does this look? https://photos.app.goo.gl/2iZT3HmDE3A1wxJH9

@sebastian-roth I hadn’t used iperf, just a regular speed test (speedtest.net). Here are the results from iperf for ubuntu (still quite a few retries when connecting to the main FOG server):
https://photos.app.goo.gl/FDvPSgLoKVAUWDpY7

Here are the results from the command above:
https://photos.app.goo.gl/tcVtyXBZnWzbVN1B6

And here are the iperf3 results from Arch:
https://photos.app.goo.gl/qXU7b5tn8b5ohAan9

I can’t get SystemRescueCD to work as of yet, it will not connect to the network at all with that, but I’ll post the results when I get them.

@sebastian-roth Hi Sebastien, apologies again for the delayed response. I ran a live USB of Ubuntu 20.10 and network performance was normal. We also have Windows 10 loaded on one of the devices manually and it performs normally as well. It seems specific to FOG performance unfortunately.

@sebastian-roth Here you are! https://photos.app.goo.gl/WnHEE63jFEjKvT4N9

@sebastian-roth said in HP ProBook 640 G8 imaging extremely slowly:

@Jacob-Gallant I looked at the PCAP for quite some time now. We see clear signs of “network congestion” - meaning that packets are being re-transmitted causing the TCP connection to slow down.

The connection starts just fine and the host sends a file read request to the FOG server. Now the FOG server starts to send a first large packet. Standard ethernet MTU is 1518 bytes and the FOG server sends 7240 bytes in one single TCP packet - a so called jumbo frame.

So I am wondering if you can improve speed by disabling LRO (Large Receive Offload), TSO (TCP Segmentation Offload) and GSO (Generic Segmentation Offload) using ethtool. Schedule and boot into another debug deploy session. On the shell run:

ip a s
ethtool -K eth0 lro off
ethtool -K eth0 tso off
ethtool -K eth0 gso off

The first command is just to confirm the network interface name (could be eth0 or different) to use with ethtool later on. You can try disabling all three at once or just one and give it a try.

There are various I219-V cards/chips listed with different PCI IDs. Searching with 8006:15fc I couldn’t find much on the web but searching for I-219V there are a few people complaining about issues:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1802691
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1785171
https://forums.linuxmint.com/viewtopic.php?t=327435
https://access.redhat.com/solutions/3615791
Though I am really in doubt if any of those match your exact situation.

Apologies for the delay in getting back to you, I’ve been working from home so far this week so I didn’t have access to the device. Unfortunately these steps didn’t improve anything.

@sebastian-roth @george1421 Thanks to you both for all of your time. Here is the capture:

https://drive.google.com/file/d/1WS8e2R9kR-ZjpqzgikmSg0CakZJYJi4h/view?usp=sharing

@george1421 Same results with 5.10.12 I’m afraid. We were using 5.6.18 for all of the previous tests, that’s right.

@george1421 The working one is different, 8086:15e3

@george1421 said in HP ProBook 640 G8 imaging extremely slowly:

@jacob-gallant said in HP ProBook 640 G8 imaging extremely slowly:

I ran iperf on a working device and here are the results, 0 retransmits as you mentioned.

In the same network jack as the 640 G8?

The network adapter in the 640 G8 is built in or USB based?

The very same, yes. And it’s built-in.