Re: [asterisk-dev] RTP Bridging optimization
Kevin P. Fleming wrote:
Vadim Lebedev wrote:
You're right but only in the case that when you have separtae briding
threads for each direction.
I was thinkin about situation when there is ONE briging theard for two
directions. The you can you the same pipe
for both direction.
No, you cannot. How are you going to distinguish packets that belong to
the A-B direction from the ones that belong to the B-A direction if
both of them are being written to the 'write' end of the same pipe?
Instead of just proposing this idea without fully understanding how it
would work (here on the developer mailing list), it would be much better
if you wrote a small program demonstrating the technique and proving
that it is possible. Otherwise this is all just speculation and people
disagreeing about what may or may not work.
Certainly it is not at all possible to create a single pipe and using it
for both directions of multiple bridges... I don't know how you came to
the conclusion that could work at all.
Ok, i'll write a demo program this week
But the basic approach is trivial:
FD_SET(readset, source_fd);
FD_SET(readset, target_fd);
N = 1 + max(source_fd, target_fd);
select(N, readset, 0, 0, timeout);
if (FD_ISSET(readset, source_fd))
{
// copy from source to target
slice(source_fd, mypipe[0], .);
slice(mypipe[1], target_fd);
}
else if (FD_ISSET(readset, target_fd))
{
// copy from target to source
slice(target_fd, mypipe[0], .);
slice(mypipe[1], source_fd);
}
The trick is that the pipe is ALWAYS empty And when we push
something to the pipe, we pull the data from it immideately afterwards.
Thanks
Vadim
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RTP Bridging optimization
Vadim Lebedev wrote: The trick is that the pipe is ALWAYS empty And when we push something to the pipe, we pull the data from it immideately afterwards. So you've replaced a pair of read()/write() calls with two calls to splice()? It's the same number of userspace/kernelspace boundary crossings, I can't see how this would be any significant improvement at all. The whole point of splice() and tee() are to allow *streams* of data to be copied without having to bring the data from kernelspace to userspace; doing it one packet at a time will probably defeat the purpose of using them entirely. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RTP Bridging optimization
Kevin P. Fleming wrote: Vadim Lebedev wrote: The trick is that the pipe is ALWAYS empty And when we push something to the pipe, we pull the data from it immideately afterwards. So you've replaced a pair of read()/write() calls with two calls to splice()? It's the same number of userspace/kernelspace boundary crossings, I can't see how this would be any significant improvement at all. Kewin, Now, when we agree that it IS possible to use single pipe for multiple bridges let's look on benefits: As for now Asterisk when packet arrives on a briged socket 1. Thread switch to the reader thread 2. read from socket + transfer of data from kernel to user 3. thread swicth to writer thread 4. write to socket + transfer of data from user to kernel Now if my proposal is implemented in the worst case we will economise 2 thread switches, 2 user/kernel data transfers plus we'll have much less threads in the system. I think we can expect pretty dramatic improvements Thanks Vadim The whole point of splice() and tee() are to allow *streams* of data to be copied without having to bring the data from kernelspace to userspace; doing it one packet at a time will probably defeat the purpose of using them entirely. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RTP Bridging optimization
Vadim Lebedev wrote: Now, when we agree that it IS possible to use single pipe for multiple bridges let's look on benefits: I did not agree that it was possible, I told you it seemed possible but would likely provide little or no benefit. As for now Asterisk when packet arrives on a briged socket 1. Thread switch to the reader thread 2. read from socket + transfer of data from kernel to user 3. thread swicth to writer thread 4. write to socket + transfer of data from user to kernel Where are these two threads you are referring to? Asterisk call bridges happen in one thread per bridge. Now if my proposal is implemented in the worst case we will economise 2 thread switches, 2 user/kernel data transfers plus we'll have much less threads in the system. I think we can expect pretty dramatic improvements This would only be true if your assumption about two threads per bridge were true, but it is not. The only possible benefit of your proposal would be the reduced kernel/user copying, but you've replaced it with complex pipe setup and constant creation and destruction of splice() structures in the kernel. So far you haven't demonstrated any possible significant benefit from this idea, so unless you can show us a working example where your idea produces a performance improvement in any noticeable way, I don't think you will accomplish much pursuing this theory. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RTP Bridging optimization
I think this whole discussion really leads to one thing: Proof Of Concept code, as Kevin mentioned earlier. Instead of just proposing this idea without fully understanding how it would work (here on the developer mailing list), it would be much better if you wrote a small program demonstrating the technique and proving that it is possible. If worsts comes to worsts, when writing the code you will realize that it is very possible and efficient; or, the likely case of it not working and you get to figure out why and it is just one more thing that you know. :] Best of luck, -bkruse - Original Message - From: Kevin P. Fleming [EMAIL PROTECTED] To: Asterisk Developers Mailing List asterisk-dev@lists.digium.com Sent: Monday, May 14, 2007 5:38:09 PM (GMT-0800) America/Tijuana Subject: Re: [asterisk-dev] RTP Bridging optimization Vadim Lebedev wrote: Now, when we agree that it IS possible to use single pipe for multiple bridges let's look on benefits: I did not agree that it was possible, I told you it seemed possible but would likely provide little or no benefit. As for now Asterisk when packet arrives on a briged socket 1. Thread switch to the reader thread 2. read from socket + transfer of data from kernel to user 3. thread swicth to writer thread 4. write to socket + transfer of data from user to kernel Where are these two threads you are referring to? Asterisk call bridges happen in one thread per bridge. Now if my proposal is implemented in the worst case we will economise 2 thread switches, 2 user/kernel data transfers plus we'll have much less threads in the system. I think we can expect pretty dramatic improvements This would only be true if your assumption about two threads per bridge were true, but it is not. The only possible benefit of your proposal would be the reduced kernel/user copying, but you've replaced it with complex pipe setup and constant creation and destruction of splice() structures in the kernel. So far you haven't demonstrated any possible significant benefit from this idea, so unless you can show us a working example where your idea produces a performance improvement in any noticeable way, I don't think you will accomplish much pursuing this theory. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RTP Bridging optimization
Tilghman Lesher wrote: On Sunday 13 May 2007, Kevin P. Fleming wrote: Vadim Lebedev wrote: I beleive you are mistaken, the pipe syscals creates 2 file descirptors, one for reading other for writing so in worst case you need 2 pipes meaning 4 fds so first you splice to a write side of first pipe from a socket, then optioanlly in case of montiored stream tee form read side of the first pipe to the write side of the second pipe, then splice from write side of the first pipe to the target socket, then read from the read side of the second pipe to perfrom monitoring You just validated my point. A single bridge connecting two sockets requires two pipes, one for each direction between the sockets. This turns the '2 fds required' for a bridge into _6_ fds. In addition, this only works in the cases where the media streams are completely compatible, including dynamic RTP format number assignments, frame lengths and other variables. Josh also brought up a valid point on IRC. How exactly are we to direct packets to the destination IP address? Keep in mind that RTP is UDP and thus there is no specific destination with respect to the socket. If this were TCP, it would work fine, but with UDP, there is no connection. Actually you can use 'connect' syscall on udp socket, and then 'write', and 'send' syscalls will use destination address used in connect. I magin the 'splice' and 'tee' will behave same way Thanks Vadim ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] RTP Bridging optimization
Vadim Lebedev wrote: You're right but only in the case that when you have separtae briding threads for each direction. I was thinkin about situation when there is ONE briging theard for two directions. The you can you the same pipe for both direction. No, you cannot. How are you going to distinguish packets that belong to the A-B direction from the ones that belong to the B-A direction if both of them are being written to the 'write' end of the same pipe? Instead of just proposing this idea without fully understanding how it would work (here on the developer mailing list), it would be much better if you wrote a small program demonstrating the technique and proving that it is possible. Otherwise this is all just speculation and people disagreeing about what may or may not work. Certainly it is not at all possible to create a single pipe and using it for both directions of multiple bridges... I don't know how you came to the conclusion that could work at all. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] RTP Bridging optimization
I wonder if somebody considered to optimize RTP bridging using spllice and tee syscalls? Vadim ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
