Hi.

my last message was hard to read because of "sneaky" linebreaks
that found there way into the mail when copying from text editor.

I'm resending this message for better readability in the archive.

Sorry about that.

Berry

---

Hi again.

After fiddeling with pf and trying to statistically determine the cause
of the problem i did another search on the net and found this thread [1]
here there the user suggests:

"when this slow problem occurs, you must disable the checksum on the
physical and virtual cards and restart the xenserver."

Does anyone know what exactly is meant by that?

I then searched in the CVS log of xnf development [2] and found this
statement:

"Emulated em(4) or re(4) drivers will
take over if xnf(4) driver is disabled or not compiled in."

This gave lead me to the idea to disable xnf in the kernel, for now just
temporarily upon boot, for example like this [3]:

----
boot> boot bsd -c
...
ukc> disable xnf
----

As a result the booted systems now finds the `vio`

=== Case 6: Client <= VPN = Server <= WAN (vio)
* From client (10.8.0.99) download external file from WAN via VPN tunnel
* with Virtio driver
* Testresult:

----
→ curl http://fra36-speedtest-1.tele2.net/100MB.zip > /dev/null
% Total    % Received % Xferd  Average Speed   Time    Time     Time 
Current
                               Dload  Upload   Total   Spent    Left  Speed
100  100M  100  100M    0     0  2226k      0  0:00:46  0:00:46 --:--:--
4041k
----


If I'm not mistaken this gives reason to believe that there is an issue
with the xnf driver. I will mostly like contact the xnf developer about
this. In the best case xnf can be fixed and the download performance be
improved.

Thank you all.

Berry
____

[1] http://daemonforums.org/showthread.php?p=61158
[2] https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pv/if_xnf.c
[3] https://man.openbsd.org/config


Reply via email to