Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
how is the smallest value for tcp_rmem_default and tcp_wmem_default? Becauase im doing tcp tuning and my windows size is 6250 bytes (10mbit bandwith, delay 5ms and loss %0.00001) so i put tcp_rmem_default='6250' and tcp_wmem_default='6250' but it didn't work and decreased troughput. Then i put tcp_rmem_default='65536' and tcp_wmem_default='65536'and increase the Throughput, but this value default. Also i calculate windows size with 10mbit bandwith and delay 5ms and the result was 6250 bytes! So i can't understand! I hope someone can help me! Sorry for my English
I calculate windows size with 10mbit bandwith and delay 5ms and the result was 6250 byte
No it isn't.
bandwidth = 10Mbits/s = 10*1024*1024/8 bytes/s = 1310720 bytes/s
delay = 5ms = 0.005s
product = 1310720*0.005 = 6553.6
However 6250 is far too small for a TCP send or receive buffer, and has been for many years. Linux probably agrees and enforces a higher minimum.
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 days ago.
Improve this question
I am reading about ipv4 and I wonder how scientist determine the perfect size of packet for example here in RFC 791 said 512 B for payload + 64 B for ip-header
how they do that?
also what parameters they considered?
Another question is that why until now this is the same as that time?? how it still working properly, even today it get smaller!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
When 3 Duplicate Acks arrive TCP halves its congestion window, but when only 1 or 2 Duplicate Acks arrives what does TCP do ? Does it increase the congestion window like any other non duplicate Ack ?
That reaction to 3 duplicate acks is in TCP Reno. When it receives 1 or 2 duplicate ACK's it shouldn't do anything. The increase of the congestion window occurs after original ACK's are received because they indicate the communication is good and TCP is tries to get to the maximum possible throughput.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
How can I find out the specifics about an m3u8 stream? For example, what codecs / profiles the footage was built with?
Example m3u8: http://live.3gv.ifeng.com/live/zixun.m3u8
You cant determine this information from the m3u8. You must download a .ts segment and analyze the elementary stream. For H264 you need to parse the SPS, for AAC the ADTS header and for MP3 the mpeg frame header. Note the specifics can also change in the middle of the stream if a discontinuity via the m3u8, or discontinuity indicator bit in the ts is set.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Is there a table summarizing the differences of CPUs supported by Arduino? What's the lowest power Atmel processor that can be used with an Arduino?
Perhaps these are too obvious:
The official hardware page might be what you're looking for; clicking on any version brings up an overview which elaborates on each variant. There's also a list of official hardware on Wikipedia, although it might not be as up to date.
The lowest voltage for any official Arduino MCU is, as far as I know, 3.3 V. I'm not sure about the current; the forum thread Minimizing power consumption seems to elaborate further.
(Update by mh) Based on the table above, the lowest power Arduino-supported chip is the ATmega168 with 16 KB flash and 1K SRAM.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
TCP and UDP(sometimes) use a simple checksum to make sure the contents are correct.
What I want to know is any empirical data or estimate, of how often a packet is corrupted, but has the correct checksum for a person with a standard computer and internet connection.
Now I know that this probably all varies widely with ISP quality, hardware quality, and more, but I just want to hear any information on this.
You're asking how long a piece of rope is. In general, unless there's something wrong, the error rate should be less than 10-7. On the other hand, wireless, 3G, and such can have significantly higher error rates.
This Google search will show you there's a lot of literature.
From Microsoft Research,
Traces of Internet packets from the
past two years show that between 1
packet in 1,100 and 1 packet in 32,000
fails the TCP checksum, even on links
where link-level CRCs should catch all
but 1 in 4 billion errors. For certain
situations, the rate of checksum
failures can be even higher: in one
hour-long test we observed a checksum
failure of 1 packet in 400. We
investigate why so many errors are
observed, when link-level CRCs should
catch nearly all of them.
http://academic.research.microsoft.com/Paper/22436.aspx
Basically transmit 100MB+ over a typical Internet connection and you are very likely to see a silent failure.