[rds-devel] netperf patch to support RDS

[Richard Frank]

Or Gerlitz wrote:
> Zach Brown wrote:
>>> If removing the restriction on the tool to be standalone, what about
>>> crload etc programs which in past provided by Oracle along with the RAC
>>> IPC library so one can compare the performance of RDS to UDP for Oracle
>>> IPC through synthetic tool and without the need to set a data-base, is
>>> this available somehow - Rick?
>>
>> Yeah, people use crload.  Distributing it is a problem.  There's also a
>> rds-stress tool in the rds-tools repository which vaguely mimics what
>> crload does.
>
> Zach,
>
> OK, so there are actually seven numbers around:
>
> UDP     - Gbe, IPoIB datagram / connected mode
It is not valid - for performance only consideration - to compare an 
unreliable transport / protocol to a reliable one.

Netperf is too simplistic in that all it seems to do is stream data in a 
simple loop. This is not how Oracle uses the IPC and again does not 
reflect what it would take to make UDP reliable.

For this reason we are not interested in having Netperf support RDS and 
or seeing Netperf data.

Of course if others folks want to do this - for their own reasoning - 
guess it's going to happen anyway.

Just be careful to not quote Netperf data comparisons when positioning 
an IPC for Oracle.

> RDS/TCP - Gbe, IPoIB datagram / connected mode
> RDS/IB  - native
>
> An RDS capable netperf can be used to produce them all (*) and same 
> for crload. Basically people want to see four numbers, UDP/Gbe, 
> UDP/IPoIB datagram / connected mode and RDS/IB, a comparison which 
> makes sense, but is not possible with the rds tools, which can give 
> only RDS and not UDP numbers. This (the need in open-source and free 
> benchmarking tool) brings us back to the need to merge RDS support 
> into netperf.
>
> Or.
>
> (*) can you shed light how do I make RDS use the TCP transport over 
> the IPoIB network, my understanding is that it will always use the 
> native transport, correct?
>
>