Douglas Allan Tutty wrote:
Could always be a possibility, but if you take the data sent and the
time spend to send it, you would see that one server in all tests look
like it cap at around 5.8Mb/sec and the other one at 9.0Mb/sec. These
numbers are sure way to low to be a bus problem here. Even drive speed,
look to me that drives these days sure can spit data lots faster then
this for sure.
I am trying so many different things without success so far. But I am
sure there have to be something I am overlooking here. Doesn't make
sense to me that one would be cap at that level. I don't believe it
anyway, but on the other end, I am running out of idea to check and
Google doesn't provide me lots more to try that I haven't done already.
I am sure Henning can get more out of his servers then this, but I am
not sure how he does it to be honest.
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Nicolas Pitre | Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb() |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
