Running Asterisk in virtualized environments
by Saúl Ibarra Corretgé of Irontec at AMOOCON 2009
Abstract
Virtualization is quite common nowadays. Even it has lots of advantages it has some caveats. The talk will give performance tips as well as comparisons between Xen, KVM and VMWare ESX when running Asterisk, indicating and solving the problems that arised during the development.
Language: English
Additional material
Here you can find all available material for this talk.
PDFs
Audio recordings
Video recordings
- Small Version (36.52 MB)
- Medium Version (244.09 MB)
- Big Version (469.14 MB)
- Small Version (214.81 MB)
- Medium Version (525.14 MB)
The slides
There are 45 different slides. Click on them to view an enlarged version.
Transcript
Saul Ibarra Corretge: [0:02] Hello everybody. My name is Saul. I’m going to spend the next 30, 45 minutes talking about how Asterisk performs virtualized environments.
[0:16] First, a short disclaimer, English is not my mother tongue, so please, I just try my best. I hope you guys learn something, as well as I learn, during this presentation. But a bit about myself, because most of you just don’t know me. As I said, my name is Saul, but I am known as Saghul.
[0:42] While I like everything about VoIP, I discovered Asterisk several years ago and I’ve been playing around with it and with all the stuff close to Asterisk. I started testing virtualization solutions more or less three years ago. At first, it was, of course, for playing, but I saw it was quite useful. Well I love everything about free software and GNU/Linux in particular.
[1:12] I work at a company called Irontec. We are located at the north of Spain, in the Basque country. We do web design, VoIP systems, webkits. Everything we do, we do it with open source software. I always prefer open software solutions. Always trying to be at the bleeding edge, that’s one of the characteristics.
So, about this presentation, it’s already out there at the Irontec.com, under the name Saul. You can download it and you will find this presentation offered in ODP and PDF. Other configuration examples for the Asterisk, the SIPp scenarios, the KVM configuration, the [inaudible 00: [1:42] 02:06] configuration. And also you can find the raw test results, which I used to make the graphs that we are about to see. You can download it right now and just look around if you want.
[2:21] First I’d like to know how many of you have used virtualization environments for work or have used it? Quite a few. And from those who use virtualization, how many of you have tried Asterisk on that? Some. That’s fine. But so many, the first two points are not for you.
[2:44] I’ll just introduce you a little bit to the virtualization, also what types of virtualization we have. Then I’ll describe how the test-bench was setup. Then I’ll discuss the testing results. As you guys see, I just tested Xen, KVM, and a stock server with no virtualization at all.
[3:09] I was going to test VMware ESX, but I couldn’t because the hardware platform was not supported. I think it was the hard drive controller. And at last, I couldn’t test it as well. The result had to be really close to Xen, or I think so.
[3:28] So, what is virtualization? Virtualization is the ability to run several simulated machines within one single physical server. While this may look a little abstract, think in costs of space. Servers cost money and servers cost space. They consume power and all that.
[3:59] Why would we use virtualization? Well, we can have a single server with two identical machines, one for testing, one for production. So we can do all sandbox testing in our testing environment and then move it off to the production environment, so nothing happens while we are testing.
[4:20] We can also reduce costs by unifying different servers, mutual servers now, in one physical machine. For example, we can have an Apache server and we can have a MySQL server and have both virtualized within one single machine.
[4:40] We can also have different testing scenarios. For example, we can have a virtual machine with the latest Asterisk [inaudible 00:04:48] running on top of CentOS, and another virtual machine with latest 1.4 branch running Debian. So we can use it for different testing scenarios.
[5:04] Within virtualization, we also have different types of it and by using different types, we can achieve different performance. Each one has its good and bad parts, so I’ll just try to explain these.
[5:22] The most important thing about the virtualization, it’s the performance we get. As I said, we are running several simulated hosts and there is one single real one. So performance won’t be a hundred percent the same, but we need to be as close as possible.
[5:42] Performance and isolation are two concepts that are really closely related in these terms. Because we want our guests to be as isolated as they can be from the host, but this isolation, usually, gives us less performance. There are four types of mainly used virtualization types. Those are: emulation, full virtualization, paravirtualization, and operating system level virtualization.
[6:17] What do I mean by emulation? For example, with KVM, the entire hardware is simulated, so we have no access to real hardware. Well we can usually pass through the USB and all of that, but we have no access to real hardware. Guests run unmodified, so we can install our operating system on top of an emulated system, just as normal. And we can virtualize different architectures, but performance is usually poor.
[6:48] Full virtualization, here we can have, for example, shared and also KVM. It’s quite similar to emulation, but some CPU instructions are run on the real CPU, on the raw CPU, not on a simulated CPU. For doing this, we need the virtualization extensions from Intel or AMD. Those are Intel Vanderpool or AMD Pacifica extensions. They are called Intel VT or AMD P.
[7:21] Our host and guests have to be the same architecture. I assume most of you use x86. Guest operating system runs unmodified. And we often use full virtualization, instead of paravirtualization, because guest operating system runs unmodified.
[7:41] And, as we will see in the next slide, for paravirtualization we need to modify the guest operating system and, well, with closed source operating systems, such as Windows, we can’t do that. So we can use full virtualization. It gives us better performance than emulation, by the way.
[8:01] Well, in paravirtualization, guest operating system is modified so it communicates with some kind of stuff called hypervisor. The hypervisor is an extension layer to the real hardware, so the guest operating system will communicate in an easy way with that hypervisor, so the performance achieved is as good as possible.
[8:26] The performance achieved with paravirtualization…oops. Sorry for that.
[8:33] [pause]
[8:40] The performance achieved is better, so it, paravirtualization that I like.
[8:51] And the last one is the operating system level virtualization. And well, guests share resources with the host. For instance, they have the same kernel. We can categorize OpenVZ in this area, for example. The isolation can be weak, so if the virtualization system does not control heavy isolation stuff, host performance can be compromised by the guests. But, well, it works on OS very well.
[9:29] After this little introduction, I will just describe how this test-bench was set up, so you can understand how the testing was made. The equipment was an HP ProLiant ML310 server. It’s a dual Intel Xeon CPU, two gigabytes of RAM, and two hard drives on RIAD0.
[9:52] We could have used RAID5 which would have given us better hard disk performance. This is pretty important, because, as you may guess, for example, when we have 10 of the machines, there are 10 of every system accessing the hard drive at the same time, so we need it to perform really fast.
[10:17] So RAID0 gives us good performance with two disks, but we need to back it up, because otherwise we can lose data. But for production use, I recommend RAID5 or more.
[10:31] The operating system that I used was Debian 5.0, 64-bit edition. For connecting on the equipment, I used a cheap 3Com Gigabit switch.
[10:46] So, the scheme was, more or less, like this. We have the Asterisk server and, to simulate real calls, we have a SIPp instance running on a host running as a UAC that is originating calls to the Asterisk server. And on the other side, we have SIPp running in UAS mode so that it receives the calls from the Asterisk.
[11:13] Both of them use custom-made scenarios, which are little modifications from the original ones. You can see them in the compressed file. I introduced some slides before.
[11:29] The software used for testing was Asterisk itself. I used, as I said, SIPp for stress-testing, Tcpdump for sniffing RTP, because the tests I made were not just simulated. They involved bidirectional media. For having CPU disk usage, memory stats, I used a sys stat utility tool, which has two utilities.
[12:04] For example, one is sar, which makes binary stats and sadf which extracts data from the binary stats and converts it to a csv file so I can fire up Open Office and make some nice, cool, and sexy-looking graphs.
[12:24] We also had to extend system limits, because if you start stressing Asterisk, you will find that you can’t make many calls. That is because you often reach the open file descriptor limit, which, by default in Debian, is 1, 024. So we just extend the limits, the stack size, the open files, and the user process number. So we can stress the server to do that. We needed to do that. I explained why.
[13:01] The testing itself, let’s start. The testing was made this way: we sent 2, 000 with the SIPp, calls lasted 100 seconds each with the RTP bidirectional media and with 400 simultaneous calls maximum. Why 400 simultaneous calls? Well, the purpose of this testing was not to get [inaudible 00:13:34] state or what or just to test how much calls Asterisk could process.
[13:41] It was just to test if Asterisk could run well in a small, medium, environment when running virtually, because if we want to handle 1, 000 simultaneous calls, why don’t we buy a server and use it for that?
[13:58] But the thing is, maybe we are thinking about hosted PBXs. We can think about buying a really big server and host several small PBXs inside. So we really don’t need 1, 000 simultaneous calls, because otherwise we [inaudible 00:14:16] for that.
[14:18] For originating the calls, we use the first line: SIPp, pull that. The only important stuff up there is just that we used “m” is 2000 calls, the limit, with “l”, it’s 400 calls. And well, media interface, media port, and trace—stat, so we generate really cool stats in CSv.
[14:50] And for receiving the calls, we used a second line. As you can see, for having bidirectional media, we used the option rtp—echo, so that, as we saw here before, this server would originate the media to Asterisk. Then it would get here and this would echo it back. So then we have bidirectional media for all the calls.
[15:24] At the same time as we fire SIPp to start originating calls, we fire sar with those instructions. So we get process number information, Ethernet device information, open socket information, CPU information, memory information. And we take the values, each 10 seconds. We generate the binary file, stress.sar, and then with the second line we convert it to CSV.
[15:57] So, let’s look at the results. When running Xen, the total calls generated, for every case, was 2, 000, as I said. We had, more or less, 950 successful calls. I’ll explain this in a few slides. We did reach the maximum concurrent calls. We did reach the limit of 400 calls.
[16:24] When running KVM, we could only reach 530 successful calls, but we did also reach the maximum concurrent calls limit. So we were running at 400 calls simultaneously. And with no virtualization at all, we got the best results. We got 1, 000 successful calls.
[16:50] Well, these are the graphs. You can see in blue the total calls created, the successful calls in orange, and the failed calls in yellow. As you can see, well, failed calls are far off and after we go through all the graphs about calls, I will explain why this is like it is.
[17:20] As you can see, KVM performs, at least in my tests – I don’t know if maybe you’ve achieved better results, but in the tests I made, I couldn’t get better ones. And these are the results with no virtualization at all. And so why are these numbers like this? Why do we have half calls successful, half calls not successful, more or less?
[17:47] Well, that’s because the SIPp scenario used is really tight. It’s really strict. In the real world, we would expect response timeouts at the SIP layer and we may wait at least forever. The SIPp scenario is very tight in the respect of which responses it waits for.
[18:12] I mean, in the SIPp scenario, after we send an invite, we may expect a 180 answer, but if we get 183, which is not the case for example, that would not match this scenario so that would be a failed call, that at least for SIPp.
[18:31] So, I made another graph just comparing the failed calls because of maximum UDP retransmissions, which, as you can see, we say that with no virtualization at all, calls are very few, less than 20. So we can say that the other failed calls are not really failed in the terms that Asterisk couldn’t process them. They’re failed because they didn’t fit exactly this scenario.
[19:07] Well, talking about the CPU usage as you can see, we can see in blue the user applications, and the system applications in orange, and the iowait in yellow. The iowait doesn’t really matter here. But as you can see the low is more or less 70 percent when using Xen. When using KVM, we are moving out to 80 percent of CPU usage so it’s a little higher. And with no virtualization at all, we are at 45 percent.
[19:47] So, by looking at this we can conclude that when running Xen or KVM we would reach the 100 percent CPU usage earlier, and that would mean we had to stop processing calls at some point of time. But as I said before, our purpose was not to test how many simultaneous calls Asterisk could handle. It was just to test if Asterisk could handle a good number of calls for a minimum server usage.
[20:25] We’ll talk about memory again. Well really Asterisk, it’s more CPU than memory. We didn’t really have any memory issues here with the tests. As you can see this is Xen’s bytes of memory used. Both guests, KVM and Xen, used a [inaudible 00:20:53] plug for them. That’s the memory usage for KVM, and that should be the memory usage for the server running standard with no virtualization at all.
[21:07] So, as I said we have no issues here with memory. That’s not really the problem. Well, this is really important, the socket activity diagrams. Well, as I said, if we didn’t put up the limits, we could reach those annoying errors on the Asterisk like “too many open files”. So we couldn’t get more calls because we can’t open more file descriptors, for instance.
[21:41] So, by looking at the results in Xen, we are moving in more or less 1, 600 open sockets.
Man 1: [21:51] 1, 600 for 400 simultaneous calls?
Saul: [21:55] Yes, for 400 simultaneous calls.
Man 1: [22:00] So you will have four sockets per call?
Saul: [22:03] They are ITP bidirectional. You have SIP and also ITP. And in KVM, well it’s a little more irregular but we’re moving in mostly the same values. We have 1, 500, 2, 000, we are moving in there. And with no virtualization at all, we are in the same numbers.
[22:30] Well, what does this mean? As you pointed out, that’s because of the 400 calls in, because we have single in and we have ITP bidirectional. So in the three cases we reached the limit, we are pulling in the same numbers here.
[22:49] Well, now let’s talk a bit about tweaking, or what had to be done to achieve better results. We are talking about Xen domU, which is the guest, running on LVM volume. Why in an LVM volume? Because it’s really important that the hard drive is fast to run, and for the operating system to perform well.
[23:16] And in Xen we can run this from just a single file or we can have a physical partition and use it. And that’s why I used LVM and just assigned a volume to the guest so he uses a real partition and not a partition file which is less efficient.
[23:40] We also used one gigabyte of RAM, as I said. And this is important, disabling the Ethernet checksum for the domU adapter gives us better level of performance. Why? Well, because there’s no real wire between our guest network card because it’s a virtual one.
[24:04] So we really don’t need to check if our packets would go out well because they will. There’s no kind of loss on the wire because there’s no wire. So we achieve better performance by having the checksum turned off.
Man 1: [24:22] Excuse me, I’m not familiar with them actually, but don’t they have another way where you can go from an Ethernet interface bridge, because as I understand you have the host [inaudible 00:24:38] …
Saul: [24:39] No, I’m using Internet bridging for the virtual guests. But inside the guest, well, you have all those virtual interface bridged on your host, but then on your guests, you just see one adapter which you think, it’s your physical adapter. You can turn the Ethernet checksum off there in the guest, not in the host, but in the guest. And it gives you better network performance.
Man 1: [25:14] Is there a possibility to assign a physical adapter to the guest?
Saul: [25:20] Yes, in Xen we can do PCI pass-through so we can bypass PCI cards from the host to the guest. Well, it’s really good because we can for example, pass Pentium cards also, and whatever, TDM cards, we can pass it to the guest operating system also and use them there.
[25:48] Well, we have also had to tweak dahdi dummy.c so that it correctly handles timing source. Well, we won’t need this anymore. As Kelly pointed out earlier, we are having now new timing sources, as for 1.6.1 and so on. So maybe we can use them and get rid of using dahdi dummy for timing because in Xen we don’t have access to the RTC, to the real time clock, nor to the high precision event timer, or HPET.
[26:28] So we just need to correct out those lines at the start of dahdi—dummy.c so that dahdi doesn’t get confused.
Man 2: [26:36] Also, dahdi 2.2 has those changes in it, so if you want to still use dahdi because you’re not using a new enough version of Asterisk it will do the right thing in Xen anyway.
Saul: [26:48] I’m happy to hear this because I had to edit it by hand. Well, it’s a chore for your life but that I’m glad to hear.
[26:59] For KVM, well as I said KVM is a full virtualization environment, but Xen is a paravirtualization environment. Well there are some differences in here, but in KVM we can use paravirtualized drivers for block devices and for network devices.
[27:19] These drivers are called Virtio drivers. So we can have a full virtualization environment but it’s running paravirtualized drivers, so it gives us paravirtualized performance on network and block device, and that’s what we need in this case.
[27:39] So that’s what we used. You can look at the data configuration files as I said on the compressed file. We used the same testing scenario for KVM, so the guest was in an LVM volume, there was one gigabyte of RAM dedicated, and system limits were also extended.
[28:02] And so, let’s analyze a little bit the results. Well, only really few calls were dropped because of maximum UDP retransmissions, because of poor network performance. So that’s nice to hear because, well, with this amount of simultaneous calls, virtualization technologies that were tested performed well.
[28:29] The 90 percent of dropped calls exceeded response timeouts, et cetera, but of the SIPp scenario. So please don’t get confused and think that we lost half of the calls because that’s not really true. Instead of making them exactly fit the scenario, I tweaked most as I could, but it turned out that way. It’s strict in many of which responses we expect.
[29:00] And well, I didn’t see any “too many open files” messages on the Asterisk on the line, so I assume, and we know, that by extending the limits we can put up the limit of Asterisk simultaneous calls. We didn’t want to reach it because we put our limit at 400 simultaneous calls. That’s a nice number for a medium PBX, which is the one we want to virtualize.
[29:31] And well, 100 percent CPU usage was never reached, so that’s also interesting. And well, what we also know is that networking tends to be slower when running virtual. You can try it using utilities like Iperf and see that when running virtual, the networking speed slows down. So, we just…
Man 1: [29:53] Total packets? Because of packets? The packet is slow because it has to get the packets from the physical interface and then it…
Saul: [30:06] Yeah, and then go to the virtual interface.
Man 1: [30:08] This is [inaudible 00:30:09] .
Saul: [30:09] That’s the problem. So because of that we used the paravirtualized drivers in KVM. We don’t need them in Xen because they are already there. But, yeah, that’s the one.
[30:20] And well, I have to go in a little bit what issues arose during the testing period because well, the important thing is that if we want to stress an Asterisk server, we have to have bigger Asterisk or a bigger server on the other side because otherwise the stress machine would get stressed before, which was the thing that happened to me.
[30:44] I was generating calls with my workstation and it blocked, and I was like, “How the hell is this happening? I don’t even have 300 simultaneous calls.”
[30:56] Well, I took a bigger machine and then I could make good tests. If we want to try 500 simultaneous calls to Asterisk we have to divide them at least to do the load and attack the Asterisk server with several laptops or workstations because one single machine can’t stand with all that, at least with RTP, which was the case.
[31:22] I also had issues with SIPp. If you download latest release from SourceForge, you’ll see that it doesn’t compile. It says, “See the line on htp file”. But well, after trying that release, after doing checkout and run, I found that the most stable release for me was the snapshot from the 21st of January of this year. I got segmentations faults with other releases and didn’t with this one, so I’m happy with this release.
[32:01] It’s also really important to have the network isolated when doing testing because if we are going through our office switch where all machines are connected, our results can get altered and we can’t get what we really want. We want just our traffic. If someone is downloading currently with BitTorrent or anything like that, results can get altered. So for testing, the best is to have the network isolated.
[32:36] And so, what are the conclusions I get from all this? Well, as Obama said, “Yes we can.” We can use Asterisk in a virtualized environment. It runs, it works, that’s nice. But we have to take into account some performance factors which I named there three. We have this drive, well, we can use a fast hard drive, we can use SAS, we can use [inaudible 00:33:04], RAID5, et cetera, just as fast as we can.
[33:10] With networking it’s also really important. So if we use a full virtualization environment such as KVM, we should use paravirtualized drivers. Also, we should spend money on expensive and good network cards because that really matters.
[33:31] And the CPU is also really important. As we are sharing, that’s the important word here. When we are running several virtual machines, we are sharing the resources from the physical one. So we need to have lots of CPU power and lots of networking power so that when there’s stress, each one gets what it needs.
[33:54] Well, as I said, we tested a decent amount of simultaneous calls, which I’ll repeat was 400. But if we want more power, well, why not use a similar server for that? We are here, we are testing virtualization. We really don’t want to virtualize 10, 000 simultaneous calls on Asterisk. That doesn’t make sense.
[34:22] Well, there are also some advantages while using virtualization. We can use cards, we can use TDM or ISDN cards on the virtualized guests. We have PCI pass-through so if we have for example two four PRI cards on the server we can have two virtual machines assign a card to each one. So we have two servers running parallel within one single physical machine. And that is cost reduction which we talked about on the first two slides.
[35:01] And well, I found that especially for testing purposes, because I like to test lots of stuff: late [inaudible 00:35:08] release later, pre-switch everything. If we go to use virtualization we can make different sandboxes for our testing, without breaking anything.
[35:21] And well, thank you all for watching, and I have to thank also Amoocon for letting me come up here and tell this stuff. If you have any questions I’ll be happy to hear and try to answer.
Man 1: [35:38] You have ID’d what the time span was for the calls. Do you have an idea of the time of the number of calls for the second example?
Saul: [35:46] Yeah, maybe it wasn’t in the line but, the pace, well, I forgot to put that. The pace was five new calls per second, and SIPp stops starting new calls when it reaches the limit. So you have five, five, five, five, five, when you reach 400, then it stops and when calls come up it starts five, five, five, all again.
Man 2: [36:16] So on this machine you, under Xen you had precision [inaudible 00:36:24] 70 percent.
Saul: [36:25] 70 percent of CPU usage.
Man 2: [36:27] So basically you can’t try out all the possibilities for discussion.
Saul: [36:32] Yes, because I have more calls. It’s just one call for the…just one call. So if I have eight calls on the SQL server, 1000 RAM, I could assign one or two calls for each SQL servers, so each one has what it needs. I forgot to mention that, but it’s eight bit, guest-run with one single call and one device.
Man 3: [37:10] Have you logged the time difference between the ongoing and the actual? Have you logged the time lag between the coming out of a packet -
[37:26] [cross talk]
Man 2: [37:32] Virtualization adds latency to all the SIPps [inaudible 00:37:37] and all that. How many more milliseconds are we adding?
Saul: [37:42] I didn’t measure it, have fun with that. I didn’t measure if it was five or ten milliseconds. But it’s not enough to get it bad. I mean, it runs well. If you are running virtual, you don’t get 100 milliseconds of latency because of that. Because in working, KVM devices are really good.
[38:10] Virtual ones are good, and Xen ones are also really good. They are integrated to the Xen kernel which is supposed to route to main line in the 2.6.30 Linux. They really perform well.
[38:24] You don’t have the working power you have with a physical network card. But one piece of advice that if you are about to use an application which really has a huge network, you should visually pass through a real network card so you get the same components. Yeah?
Man 3: [39:03] When doing the tests, you really didn’t test stuff that CP is good at. So for these tests, I would prefer to actually use Asterisk for generating a much longer load. Because as you say, CP is extremely strict in the dialogues, and Asterisk can actually accept other messages, and it’s easier to [inaudible 39:28] network fallacy.
[39:29] Also I’m not sure of a couple other things. It might be that Asterisk is the tool I use for everything, because everything is a language.
Saul: [39:35] Well, I used CP because…
Man 3: [39:37] In this test scenario, Asterisk would have been perfectly good if you have two or three laptops on each side of the server.
Saul: [39:46] That’s true. I just used CP because, well I don’t use it much, and I like to learn a lot. And also because by reading, juggling around with Asterisk stress testing, CP comes around every time.
Man 4: [40:04] With stress test Asterisk, if you had measured the difference between running Asterisk in the different departments, Asterisk would do perfectly well. But if you really want to stress and see if both the machines handle an attack of 500 calls within no time, CP would be the tool to use.
Man 1: [40:24] If you would use Asterisk, this also would not be exactly the same, and you couldn’t try to estimate what it would be because of hardware [inaudible 00:40:38] . You get five calls a second. There might be 50 calls a second at a time. So you would no longer have formed a stable line. You would see a performance difference between beginning [inaudible 00:40:58] .
[41:00] [crosstalk]
Saul: [41:02] Maybe could script that line. It would have been hard, I guess. Any other questions?
Man 1: [41:14] Yeah, I was actually trying some stuff with CP, and basically you can often find some optional responses. The title is a problem if it’s between 180, 183 sar. If you catch a bit more than you have… Let’s say you wanted fire statistics, but you get out those messages that [inaudible 00:41:32] .
Saul: [41:33] Well, I got a provisional response that Asterisk was about to respond to me. Those were the messages that came. Many, by tuning up the scenario, results would have been a little different. But I was happy to see that they really performed well, which was the point.
Man 2: [42:02] Isn’t it possible to configure [inaudible 00:42:08] there are no provisional…
Saul: [42:14] I don’t know that I can answer that question for you.
Man 3: [42:19] You’ll always get some provisionals. I mean, you have to get some…
[42:25] [crosstalk]
Man 3: [42:28] We can’t have always the same. It’s tough to compare this in Asterisk but it’s in a different way. But you can in CP, actually, you can accept different scenarios. But it’s not as easy as in the Asterisk Outbound. And saying that that was Asterisk Outbound is easy, well, can be discussed. It’s really hard, but you can have CP handle those equations. It’s doable. But CP is a tool for real sick men.
[43:09] [laughter]
Man 3: [43:13] That’s also true somewhere in Asterisk SVN, they can take Asterisk, I forgot correct name of that, can take Asterisk SIPp back and CCP dumps on those, and convert them to SIPp scripts for testing.
Man 2: [43:30] No, it’s not in Asterisk, it’s a separate tool.
Man 3: [43:32] Yeah, it’s a separate tool somewhere in our SVN, somewhere it has a conversion.
Man 2: [43:36] It takes a packet capture and turns it into a SIPp scenario.
Man 3: [43:39] Yeah, so if you have a scenario that you really want to test and then try to develop a taste for, it creates a SIPp scenario so you can repeat stuff.
Saul: [43:49] I really didn’t know that it existed.
Man 2: [43:52] Yeah, it hasn’t been published much, it’s just out there.
Man 3: [43:56] What’s it called?
Man 2: [43:57] It’s called Sniff to SIPp, S-N-I-F-F- to -S-I-P-P. Yeah, it’s in our public SVN repository.
Saul: [44:06] Well, I’ll check it later today.
Man 2: [44:09] Yeah, so you can just give it a packet capture and tell it whether you want a scenario to be in UAC or to be in UAS, and it will just give you one. I guess you should probably announce that somewhere. I guess it is rather handy.
Man 3: [44:28] I think there’s been a few merits while [inaudible 00:44:31] has been grounded. No big front power.
Man 2: [44:33] No.
Saul: [44:36] Are there any other questions?
Man 4: [44:41] Why did you put the stack to unlimited?
Saul: [44:43] Sorry?
Man 4: [44:45] When you started, when you described your settings you said your limit was -s unlimited. It says that it would slow down your machine quite a lot.
Saul: [44:55] Well, because if I didn’t do that I would get too many open files errors, and I couldn’t…
Man 4: [45:02] On stack?
Saul: [45:03] No, sorry, on stack was because of SIPp. SIPp bought on and I got segmentation faults if I didn’t write the stack body. So I found that setting it to unlimited just worked for me. Maybe it’s not the best setting but it’s the setting that made the stress machine generate all the necessary traffic to the Asterisk server.
[45:38] Well, so I think that’s all. Thanks very much.
[45:41] [applause]