Peer Channel performance

Hi all!

I am building a p2p application using WCF and the peer channel and one of
the requisites of this application is to be able to send the higher number of
updates per second. While doing some profiling, I noticed that server was
sending (at least the sending method executed and returned) at the rate I had
specified but clients were receiving at a variable rate. For instance, I
specified an update rate of 170 miliseconds on the server and logs said it
was sending more or less at that rate. But the logs on the client side were
different: they showed a quite variable receiving rate (i.e. 171, 12, 189,
12, 231, 11, 171, 12, 232, 12, 187, ...), it seems as there was some kind of
buffering that waits till having a pair of messages before doing the real
sending.

Of course there is some computing work on the client side, but they are
around a few miliseconds on a separate thread from the receiving process.
Then I looked for some answers on the net and I met a post on Kenny Wolf's
blog, http://kennyw.com/indigo/51, that talks about the channel property
MaxBufferPoolSize. I have tried his recommendations (to assign 0 to
MaxBufferPoolSize) but without the expected results. Also I found on MSDN
that "The value of MaxBufferSize cannot be less than MaxMessageSize whose
default value is 65536 bytes (64 KB). "(MSDN link:
ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.WinFX4VS.1033/cpref20/html/P_System_ServiceModel_NetPeerTcpBinding_MaxBufferPoolSize.htm).

Anyone solved something similar? Any advice/clue?

The message buffers and the pools apply to memory management for individual
messages. Two messages never end up in the same buffer. The buffer pools are
a memory management optimization technique that keeps a number of
preallocated buffers around.

As for the problem at hand -- network communication and thread management
comes with cost and therefore you can't expect a clockwork-like receive rate
of one message per 170ms. That said, it simply looks to me as there were two
messages sent in each of your 170ms cycles. One comes in after 170-230ms and
the next one right thereafter. For someone else to analyze this better, you
need to give more information, though. What's your binding config, what does
your contract look like, and how do you create the logs you are citing?

You may want to enable message tracing if you haven't done so.

Check out Mike Taulty's summary:
http://mtaulty.com/blog/archive/2005/12/15/9018.aspx



"Jose Antonio" <JoseAntonio@discussions.microsoft.com> wrote in message
news:91215C38-9808-4F6E-86D6-F326E5E4F248@microsoft.com...
> Hi all!
>
> I am building a p2p application using WCF and the peer channel and one of
> the requisites of this application is to be able to send the higher number
> of
> updates per second. While doing some profiling, I noticed that server was
> sending (at least the sending method executed and returned) at the rate I
> had
> specified but clients were receiving at a variable rate. For instance, I
> specified an update rate of 170 miliseconds on the server and logs said it
> was sending more or less at that rate. But the logs on the client side
> were
> different: they showed a quite variable receiving rate (i.e. 171, 12, 189,
> 12, 231, 11, 171, 12, 232, 12, 187, ...), it seems as there was some kind
> of
> buffering that waits till having a pair of messages before doing the real
> sending.
>
> Of course there is some computing work on the client side, but they are
> around a few miliseconds on a separate thread from the receiving process.
> Then I looked for some answers on the net and I met a post on Kenny Wolf's
> blog, http://kennyw.com/indigo/51, that talks about the channel property
> MaxBufferPoolSize. I have tried his recommendations (to assign 0 to
> MaxBufferPoolSize) but without the expected results. Also I found on MSDN
> that "The value of MaxBufferSize cannot be less than MaxMessageSize whose
> default value is 65536 bytes (64 KB). "(MSDN link:
> ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.WinFX4VS.1033/cpref20/html/P_System_ServiceModel_NetPeerTcpBinding_MaxBufferPoolSize.htm).
>
> Anyone solved something similar? Any advice/clue?

Hi Clemens,

This is how my endpoint and binding look like:
<endpoint name="SimServerEndpoint"
address="net.p2p://eCoology/SimServer/updates"
binding="netPeerTcpBinding"
bindingConfiguration="b1"
contract="eCoology.Shared.Simulator.Broadcast.IServer">
</endpoint>

<binding name="b1"
port="36001"

resolverType="Microsoft.ServiceModel.Samples.CustomPeerResolver, ServerGUI"

peerNodeAuthenticationMode="None" />

This is the contract.

[ServiceContract(Session=false)]
[PeerBehavior]
public interface IServer
{
[OperationContract(IsOneWay = true)]
void WorldUpdate(CWorldUpdate WorldUpdate);
}

Our app is a game-like app and we wanted to use p2p technology to distribute
the updates (positions, orientations,...) among clients.

The logs I cited just contained the total amount of messages sent and the
elapsed time between each update send at server, and elapsed time between
each update reception at clients. Because each simulation at server takes
less than 10ms in average, an sleep is done (at the thread that does the
update and sends the messages) to avoid flooding clients. Therefore, server
send update messages at a known rate. At clients, I put this code to register
messages time arrivals:

public void WorldUpdate(CWorldUpdate WorldUpdate)
{
update = WorldUpdate;
currentTime =
Microsoft.Samples.DirectX.UtilityToolkit.FrameworkTimer.GetTime();
times[nmsg] = (currentTime - lastTime)*1000;
lastTime = currentTime;
//increase the number of update message received and processed
nmsg++;
}

I had already read Mike Taulty's post and used; it helped me to solve some
issues but in this case, as there is no errors (exceptions), I don't know how
to use E2E logs to solve the problem. Which level of info use? What to look
at or look for? Why the message size is always N/A?

Is peerchannel the right choice for the update rate we want to achieve? Or
should we think to use the native side of p2p, Graphing/Grouping?

Thanks in advance.

"Clemens Vasters [MSFT]" wrote:

> The message buffers and the pools apply to memory management for individual
> messages. Two messages never end up in the same buffer. The buffer pools are
> a memory management optimization technique that keeps a number of
> preallocated buffers around.
>
> As for the problem at hand -- network communication and thread management
> comes with cost and therefore you can't expect a clockwork-like receive rate
> of one message per 170ms. That said, it simply looks to me as there were two
> messages sent in each of your 170ms cycles. One comes in after 170-230ms and
> the next one right thereafter. For someone else to analyze this better, you
> need to give more information, though. What's your binding config, what does
> your contract look like, and how do you create the logs you are citing?
>
> You may want to enable message tracing if you haven't done so.
>
> Check out Mike Taulty's summary:
> http://mtaulty.com/blog/archive/2005/12/15/9018.aspx
>