I am using a Packet Capturing and Analysis Tool named as Cisco Joy for generating network flows.
Here is the link: https://github.com/cisco/joy
So Joy is a Packet capturing and analysis tool which uses a configuration file to capture Packets on a network interface and return json files as output in a directory.
I have configured Cisco Joy with AF_Packet to generate the network flows.
So I have been trying to process the network packets using tcpreplay on a virtual network interface at a speed of 3 GBPS but Joy is not receiving the packets at the same speed.
Actual: 450889 packets (397930525 bytes) sent in 1.06 seconds
Rated: 374307598.1 Bps, 2994.46 Mbps, 424122.22 pps
Flows: 12701 flows, 11947.01 fps, 450298 flow packets, 591 non-flow
Statistics for network device: vth0
Successful packets: 450889
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0
Packets Received from Cisco Joy: 260850
So Here tcpreplay sent over 400k packets but Cisco Joy received only around 260k.
I have changed the buffer size of the length in which the packets have been captured but still I didn't find any resolution from that so anyone have any clue about this?
Related
Problem: How can I detect when the audio UAC1 gadget is used from a host device?
Background: I created a USB audio gadget using USB Audio Class 1 (UAC1) to send/receive audio over USB from a Linux device to/from a Windows host. The gadget is already working and Windows detects the device as an audio in and output. I am also able to send and receive audio over the gadget using alsa and jack.
Detailed Problem: I'm trying to connect two different audio devices with Jack to route an incoming signal from audio-device-1 to the output of audio-device-2. To do this, I'm working with the virtual wiring of Jack. This works already fine, but I run into the problem that if the gadget device is not actively selected as audio in and output in a DAW or other program on the host computer (e.g. Windows), Jack gets a "poll time out" error and the virtual wiring has to be restarted.
$ jackd -r --name default -d alsa --device hw:2 -r 48000 -p 64 -n 2
jackdmp 1.9.17
....
creating alsa driver ... hw:2|hw:2|64|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 64 frames (1.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format
ALSA: use 4 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian in 3bytes format
ALSA: use 4 periods for playback
ALSA: poll time out, polled for 2000981 usecs, Retrying with a recovery, retry cnt = 1
ALSA: poll time out, polled for 2000979 usecs, Retrying with a recovery, retry cnt = 2
ALSA: poll time out, polled for 2000982 usecs, Retrying with a recovery, retry cnt = 3
ALSA: poll time out, polled for 2000979 usecs, Retrying with a recovery, retry cnt = 4
ALSA: poll time out, polled for 2000988 usecs, Retrying with a recovery, retry cnt = 5
ALSA: poll time out, polled for 2000989 usecs, Reached max retry cnt = 5, Exiting
JackAudioDriver::ProcessAsync: read error, stopping...
I would like to solve this automatically e.g. via a shell script that detects when the gadget driver is requested by the host and I then start the virtual cabling with Jack.
For this it is necessary to be able to read whether the gadget driver is in use or not.
Is there any directory / file where I can detect, if the audio gadget device is in use?
I need to find out what is the average size of request in gRPC when Im sending a string to server and receiving a string from server?
I read somewhere it should be around 20 Bytes but what I see in Network Monitor app is that the request is above 500 Bytes. So is it the smallest possible size of a gRPC message size or what?
For a single rpc, gRPC needs to do a few things:
Establish HTTP/2
(Optional) Establish TLS
Exchange headers for the RPCs (size depends on schema)
Exchange actual RPC messages (size depends on schema)
Close connection
gRPC is meant to be used for many RPCs on a single connection so the smallest possible rpc message is really the bytes used for 4.
[Edit]
I checked and the minimum data exchanged for an rpc is over 500 bytes, in terms of raw IP packets.
I used the gRPC helloworld.proto, changed to send an int32.
Inspecting packets in Wireshark showed the following IP packet totals:
1286 bytes to establish connection, exchange headers and do the first rpc
564 bytes for each subsequent rpc
176 bytes for client Shutdown
Of those 546 "minimum" bytes:
67% was TCP/IP overhead (acknowledgements, packet headers)
10% was "trailer" data sent after the rpc
In the load test the following scenarios are included
users viewing video, listening to audio, viewing pdf, ppt,etc
100 and 200 concurrent users with these scenarios what is the minimum bandwidth(mbps) for these scenarios?
Normally you should have some form of NFR or SLA stating something like:
user with mobile phone connected to 3G network should have response time not more than 2 seconds
So you need to determine the slowest supported network type and simulate users connected to this networks type accessing your application. You can use Duration Assertion to automatically fail the requests which response time exceeds acceptable thresholds.
Here are the most popular throttled data presets which can be useful:
Bandwidth | cps
GPRS | 21888
3G | 2688000
4G | 19200000
WIFI 802.11a/g | 6912000
ADSL | 1024000
100 Mb LAN | 12800000
Gigabit Lan | 128000000
I have weird performance issues with fetch.max.message.bytes parameter in librdkafka consumer implementation (version 0.11). I run some tests using kafkacat over slow speed network link (4 Mbps) and received following results:
1024 bytes = 1.740s
65536 bytes = 2.670s
131072 bytes = 7.070s
When I started debugging protocol messages I noticed a way to high RTT values.
|SEND|rdkafka| Sent FetchRequest (v4, 68 bytes # 0, CorrId 8)
|RECV|rdkafka| Received FetchResponse (v4, 131120 bytes, CorrId 8, rtt 607.68ms)
It seems that increase of fetch.max.message.bytes value causes very high network saturation, but it carries only single message per request.
On the other hand when I try kafka-console-consumer everything runs as expected (I get throughput 500 messages per second over the same network link).
Any ideas or suggestions where to look at?
You are most likely hitting issue #1384 which is a bug with the new v0.11.0 consumer. The bug is particularly evident on slow links or with MessageSets/batches with few messages.
A fix is on the way.
I'm trying to understand the TCP session. I tested a connection using TCP and I realise that initial the header options were with 20 bytes, but after the first ACK the header options were with 12 bytes.
Why the change? Because there isn't options available?
Some TCP options are only sent with the SYN packet:
Maximum segment size
Window scale
Select acknowledgement
TCP Alternate Checksum request
Looking at one of my network traces, the TCP header was 4 bytes larger in the SYN packet because of the maximum segment size option. You could use Wireshark to see which options are being sent in your traffic.
The Wikipedia page has more detail.