Measuring bandwidth usage between several local WebRTC instances - webrtc

I have a prototype WebRTC application and I want to measure the bandwidth usage for a given peer at different scenarios. For example, measuring the up/down bandwidth usage when connected to 4, 8, 12 other peers.
I only have a few machines available, so my first thought was to just launch multiple instances per machine. But how do I measure the bandwidth usage correctly? I tried using Wireshark and NetLimiter, but I started getting weird results.
The problem was that I only measured bandwidth usage between the machines and not between the actual peers themselves.
For example, if I have 2 machines with 4 peers each, I want to measure a given peers bandwidth usage with the other 7 peers, even though 3 of the peers are actually on the same machine. Any ideas on how to go about this?

Related

How to increase RabbitMQ low publish rates performance

I'm using RabbitMQ 3.6.10.
Having 16GB RAM on the machine and set water benchmark to 6GB. 4 cores.
I'm trying to perform some tests on Rabbit. Creating 1 publisher and no one that will consume the messages.
When creating 1 connection with 1 channel publishing unlimited messages one after another the management UI shows that average publish/s in ~4500.
When increasing the number of channels/connections and do it parallel in different kinds of combination i can see that it also not writing more than ~4,500.
I saw many benchmarks that talk about many more messages per second.
I can't figure what can cause the bottleneck? Any ideas?
In addition, when using many channels with many messages I get to some point that the Rabbit RAM is full and it blocks the publishers from publishing more messages. This is a good behavior but the problem is that the Rabbit stops writing to the disk and it stuck in this status forever. Any ideas?

Is there a way to send two udp streams over a xen paravirtualized system taking separate routes over 2 VMs to the same destination computer?

I'm working on my second experiment for my master thesis and my supervisor had some requirements on this experiment and I don't really know how to proceed. Earlier I was thinking that it should be just to forward the packets but now facing the problem hands on I don't know where to begin.
The setup is Computer 1 ->Measurement point->System Under Test->Measurement point-> Computer2
The System Under Test consists of 2 VMs created with the XEN management tool XL.
There is a bridge from computer 1 on the interface "eth0" to "SUT" which is connected to the VM and the same thing on the otherside to computer 2.
I'm going to send 2 UDP streams and compare the timestamps over the measurement points with two servers on computer 2. The streams are going to be separated by port number and keyid for the stream.
My question is how do I make one of the UDP stream take the route through one of the VMs and the other UDP stream to take the other route?

Monitoring home network activity

I have a somewhat complex home network and I want to be able to monitor network activity both inbound/outbound. My network consists of 5 VLANs to segregate unmanaged network, user devices network, guest network, home automation network, and management network.
I have a ESXi server with 2.4GHz 8-c Atom CPU and 32GB memory. I have 2-c and 8GB remaining that I can dedicate. My 48 port switch is also managed.
I searched online and read various tools like Snort, Untangled, Sophos Home UTM, etc but I'm not sure if I need several of them, or just one, and how it will provide monitoring of my network to know if any suspicious activity is found.
Some extra features, but not necessary, would be to check mail (spam) and openVPN integration. I'd also like a daily report if possible to know how much inbound/outbound bandwidth was consumed. It can be emailed or viewed online.
I don't mind paying for a service, I can probably afford $100-$250 a year for annual subscription. It just has to handle multiple VLANs, and something like 80+ IP addresses.
I can't help you regarding monitoring for suspicious ativity, but for monitoring of the health of the network there are various tools.
PRTG is a Network monitoring tool which is free up to 100 sensors.
I don't know if they mean 100 host or if one host can consist of multiple sensors.
I don't really have any experience using it, but I know it is widely used for monitoring network health and bandwidth usage.
MRTG can also be used if only bandwidth usage is of interest.
HP NNM is another tool for monitoring.
It's very powerful and has alot of plugins (SPi). It can be used with HP NPS for statistics.
I know the have a free version for trail which should be limited to a number of hosts.
http://www8.hp.com/us/en/software-solutions/network-node-manager-i-network-management-software/

Detecting Connection Speed / Bandwidth in .net/WCF

I'm writing both client and server code using WCF, where I need to know the "perceived" bandwidth of traffic between the client and server. I could use ping statistics to gather this information separately, but I wonder if there is a way to configure the channel stack in WCF so that the same statistics can be gathered simultaneously while performing my web service invocations. This would be particularly useful in cases where ICMP is disabled (e.g. ping won't work).
In short, while making my regular business-related web service calls (REST calls to be precise), is there a way to collect connection speed data implicitly?
Certainly I could time the web service round trip, compared to the size of data used in the round-trip, to give me an idea of throughput - but I won't know how much of that perceived bandwidth was network related, or simply due to server-processing latency. I could perhaps solve that by having the server send back a time delta, representing server latency, so that the client can compute the actual network traffic time. If a more sophisticated approach is not available, that might be my answer...
The ICMP was not created with the intention of trying those connection speed statistics, but rather if a valid connection was made between two hosts.
My best guess is that the amount of data sent in those REST calls or ICMP traffic is not enough to calculate a perceived connection speed / bandwidth.
If you calculate by these metrics, you will get very big bandwidth statistics or very low, use as an example the copy box in windows XP. You need a constant and substantial amount of data to be sent in order to calculate valid throughput statistics.

Do ping requests put a load on a server?

I have a lot of clients (around 4000).
Each client pings my server every 2 seconds.
Can these ping requests put a load on the server and slow it down?
How can I monitor this load?
Now the server response slowly but the processor is almost idle and the free memory is ok.
I'm running Apache on Ubuntu.
Assuming you mean a UDP/ICMP ping just to see if the host is alive, 4000 hosts probably isn't much load and is fairly easy to calculate. CPU and memory wise, ping is handled by you're kernel, and should be optimized to not take much resources. So, you need to look at network resources. The most critical point will be if you have a half-duplex link, because all of you're hosts are chatty, you'll cause alot of collisions and retransmissions (and dropped pings). If the links are all full duplex, let's calculate the actual amount of bandwidth required at the server.
4000 client #2 seconds
Each ping is 72 bytes on the wire (32 bytes data + 8 bytes ICMP header + 20 bytes IP header + 14 bytes Ethernet). * You might have some additional overhead if you use vlan tagging, or UDP based pings
If we can assume the pings are randomly distributed, we would have 2000 pings per second # 72 bytes = 144000 bytes
Multiple by 8 to get Bps = 1,152,000 bps or about 1.1Mbps.
On a 100Mbps Lan, this would be about 1.1% utilization just for the pings.
If this is a lan environment, I'd say this is basically no load at all, if it's going across a T1 then it's an immense amount of load. So you should basically run the same calculation on which network links may also be a bottle neck.
Lastly, if you're not using ICMP pings to check the host, but have an application level ping, you will have all the overhead of what protocol you are using, and the ping will need to go all the way up the protocol stack, and you're application needs to respond. Again, this could be a very minimal load, or it could be immense, depending on the implementation details and the network speed. If the host is idle, I doubt this is a problem for you.
Yes, they can. A ping request does not put much CPU load on, but it certainly takes up bandwidth and a nominal amount of CPU.
If you want to monitor this, you might use either tcpdump or wireshark, or perhaps set up a firewall rule and monitor the number of packets it matches.
The other problem apart from bandwidth is the CPU. If a ping is directed up to the CPU for processing, thousands of these can cause a load on any CPU. It's worth monitoring - but as you said yours is almost idle so it's probably going to be able to cope. Worth keeping in mind though.
Depending on the clients, ping packets can be different sizes - their payload could be just "aaaaaaaaa" but some may be "thequickbrownfoxjumpedoverthelazydog" - which is obviously further bandwidth requirements again.