Re: [CentOS] CentOS 8 on USB disk
I usually use the command "dd if=iso of=usbdevice status=progress && sync" On Wed, 29 Jan 2020, 18:36 Erick Perez - Quadrian Enterprises, < epe...@quadrianweb.com> wrote: > That happened to me several times > My USB was "burned" and never displayed new data copied to it. > By "burned" I mean the flash drive was faulty up to a point where it always > showed a phantom image of what WAS in the pen drive. > > But YMMV > > On Wed, Jan 29, 2020, 11:56 AM J Martin Rushton via CentOS < > centos@centos.org> wrote: > > > What's your dd command? Are you sure you are writing to the raw disk > > and not inside a partition? > > > > On 29/01/2020 16:30, Jerry Geis wrote: > > > Well after a closer look - Seems like the OLD 8.0 iso image is still on > > the > > > USB. Not the new 8.1 > > > > > > I have tried to redo the dd command to copy the 8.1 iso - I get no > > errors - > > > but it still comes up with the 8.0 > > > I then tried to remove the partitions, save and recopy. still same old > > boot > > > menu. > > > > > > Is there a trick to write over the UEFI stuff ? > > > > > > Jerry > > > ___ > > > CentOS mailing list > > > CentOS@centos.org > > > https://lists.centos.org/mailman/listinfo/centos > > > > > > > -- > > J Martin Rushton MBCS > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On 1/29/20 3:26 PM, hw wrote: > On Wednesday, January 29, 2020 6:52:50 PM CET Nataraj wrote: > [...] >> By burst, I mean that you don't have a bandwidth commitment with an SLA >> from your provider. A bandwidth commitment means that you are paying a >> provider to guarantee you so many MB or GB of bandwidth and this is >> guaranteed to you. This means it is allocated to you in their network >> allotments and you can use it at any time. > Isn't that called more like "guarantied bandwith" than "burst"? burstable bandwidth is the opposite of guaranteed bandwidth. > > [...] Well it sounds like you know where your problem is then. If your current provider can't solve the problems to your satisfaction then you probably need to find a different provider. >>> Well, I don't know, I can only be like 99% sure that the problem is with >>> the VOIP provider. Changing the VOIP provider would be very difficult >>> because there aren't many left to begin with, and even fewer allow >>> encrypted connections. And try to find one that has a useful support ... >>> I might end up with not having a phone anymore, and that would make >>> things extremely difficult. >> I can't really speak for the situation in your country. One more thing >> comes to mind. I don't remember if anyone has mentioned that the 1 way >> voice problem can be caused by an issue with the stateful packet filter >> in your firewall. I.E. your firewall has become confused and thinks >> the UDP connection (we'll not really a connection) is no longer active, >> so it blocks the packets, creating the one way voice scenario. Most >> phone switch software and VOIP phones have things that can be configured >> to send extra packets to fool the stateful packet filter into allowing >> necessary packets to flow. I've never set this up in asterisk, but I >> suggest you look into it. > How does a firewall allow the desireable SRTP packets to traverse it in the > first place? My firewall is CentOS running iptables, so you would use something like iptables -A INPUT -p udp -m state [OTHER MATCH OPTIONS] --state ESTABLISHED -j ACCEPT You would similarly code an OUTPUT rule. You obviously need to permit whatever packets/ports your voice thisapplications requires i.e. SIPS srtp etc. I generally limit my voip packets to the IP addresses of any pops that I connect to. There are hackers out there that will connect to your phone switch if you allow voip packets from any source. Most commercial firewalls have options to enable VOIP services. > > How would the packets being blocked explain asterisk showing replay errors > and > authentication failures? Packets that aren't there can hardly cause such > errors. I don't know. Maybe the 1 way voice problem is different than the replay errors. I'm just throwing out ideas, you'll have to determine if they apply to your situation or not. > > BTW, the VOIP provider is fixing or has fixed the problem now. It turned out > that they need or needed to update the firmware of some network adapters > because the old firmware has been causing issues. A test call showed no > errors on both sides for over 45 minutes. > > > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On Wednesday, January 29, 2020 6:52:50 PM CET Nataraj wrote: [...] > By burst, I mean that you don't have a bandwidth commitment with an SLA > from your provider. A bandwidth commitment means that you are paying a > provider to guarantee you so many MB or GB of bandwidth and this is > guaranteed to you. This means it is allocated to you in their network > allotments and you can use it at any time. Isn't that called more like "guarantied bandwith" than "burst"? [...] > >> Well it sounds like you know where your problem is then. If your > >> current provider can't solve the problems to your satisfaction then you > >> probably need to find a different provider. > > > > Well, I don't know, I can only be like 99% sure that the problem is with > > the VOIP provider. Changing the VOIP provider would be very difficult > > because there aren't many left to begin with, and even fewer allow > > encrypted connections. And try to find one that has a useful support ... > > I might end up with not having a phone anymore, and that would make > > things extremely difficult. > > I can't really speak for the situation in your country. One more thing > comes to mind. I don't remember if anyone has mentioned that the 1 way > voice problem can be caused by an issue with the stateful packet filter > in your firewall. I.E. your firewall has become confused and thinks > the UDP connection (we'll not really a connection) is no longer active, > so it blocks the packets, creating the one way voice scenario. Most > phone switch software and VOIP phones have things that can be configured > to send extra packets to fool the stateful packet filter into allowing > necessary packets to flow. I've never set this up in asterisk, but I > suggest you look into it. How does a firewall allow the desireable SRTP packets to traverse it in the first place? How would the packets being blocked explain asterisk showing replay errors and authentication failures? Packets that aren't there can hardly cause such errors. BTW, the VOIP provider is fixing or has fixed the problem now. It turned out that they need or needed to update the firmware of some network adapters because the old firmware has been causing issues. A test call showed no errors on both sides for over 45 minutes. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On 1/29/20 4:48 AM, hw wrote: > On Wednesday, January 29, 2020 10:10:48 AM CET Nataraj wrote: >> On 1/28/20 12:39 PM, hw wrote: >>> On Tuesday, January 28, 2020 9:00:22 AM CET Nataraj wrote: On 1/26/20 5:44 PM, hw wrote: > On Sunday, January 26, 2020 11:18:36 PM CET Pete Biggs wrote: >> First of all - disclaimer - I'm no network specialist, I just read and >> am interested in it. I may get things wrong!! >> >>> Both physical interfaces show the same. But does this mean it's on as >>> in >>> "rx- checksumming: on" or off as in "tx-checksum-ipv4: off [fixed]"? >> As far as I understand it rx-checksum is the underlying wire >> checksumming - and from what I've read about it, disabling that >> disables the UDP checksums. > You mean layer 1 checksumming? Is there such a thing with ethernet? I > think I read something about encoding, when I was trying to understand > what "bandwidth" actually means, being involved in signal transmissions; > and I seem to remember that there was no checksumming involved and it > had > to do with identifying signals as a requirement for the very possibility > to transmit something before anything could be transmitted at all. > >>> Assuming that I do not receive packets with invalid UPD checksums, >>> then >>> the >>> packages must be somehow altered and their UPD checksums recalculated >>> to >>> arrive here. Does bad hardware etc. do that? Why would the UDP >>> checksums >>> just happen to get recalculated correctly but like randomly without >>> intent? >> I'm not sure I understand what you are asking. > It is about VOIP calls via SRTP being interrupted at irregular > intervals. > The intervals appear to depend on the time of day: Such phone calls can > last for a duration of about 5--25 minutes during the day to up to 1.5 > hours at around 3am before being interrupted. My sense is you may be starting at too low of a level in trying to debug this. >>> One of the reasons I have to look into it is that it is usually good to >>> know more/better. >>> I have seen the same kind of problems with my voip service when there is a problem with my Internet connection. When this happens I also see high retransmission rates for tcp connections and other signs of network problem. >>> How do you monitor such retransmissions to be able to see if and when they >>> occur? >> netstat -s | grep -i retrans > Cool, that gives a lot of information. Retransmissions are at ~0.012/~0.029 > percent on the server/workstation, and the UPD statistics look good. > If I check the modem for my Internet connection there are issues with the signal levels and high error rates reported by the modem. If you believe your Internet connection is reliable, then if you run managed switches, check your switch logs for any reported errors. You could try tools like iperf to check for problems on your internal network. You could run some of the basic tools for testing voip performance of your Inetnet connection and if necessary run iperf to a cloud hosted system. >>> Can you suggest useful tools to analyze VOIP performance, and how do you >>> define VOIP performance? >> Well there used to be a number of speedtest like sites that use to >> report more accurately , latency, jitter and packet loss. It seems most >> of them have now scaled down their output, but you could use ping. mean >> deviation is basically jitter. >> >> I think a few of the tests listed on this site, still work. >> >> https://getvoip.com/blog/2014/05/12/20-best-voip-speed-test-tools/ > Most seem to be test for bandwidth, and none of the VOIP related sites work. > Besides, ping times to the US are usually around 200ms, so if there were any > results to be abtained, they might be questionable. > >> There used to be sites that did a calculation for something called MOS >> score, which is a measure of expected voice quality based on the >> performance of a connection. Don't know if anyone does that anymore. >> In the VOIP industry there is fancy/expensive equipment for measuring >> end to end performance, but in practice simple ping output with regular >> sampling from something like a cron job can tell you alot. > VOIP performance comes down to what you might call the human experience. > Tools only trying to measure how well data is being transferred aren't going > to measure that. The human experience is also subjective and not easy to > measure. > > For example, the network can be perfectly fine, and yet the VOIP performance > is total shit when you use a cell phone because their audio output sucks no > matter what. What can you expect from a tiny speaker built into a cell phone? > >> Basically, what you want is that if your phone system relies on your >> Internet connection, the pop that your connecting too needs to be >>
Re: [CentOS] CentOS 8 on USB disk
That happened to me several times My USB was "burned" and never displayed new data copied to it. By "burned" I mean the flash drive was faulty up to a point where it always showed a phantom image of what WAS in the pen drive. But YMMV On Wed, Jan 29, 2020, 11:56 AM J Martin Rushton via CentOS < centos@centos.org> wrote: > What's your dd command? Are you sure you are writing to the raw disk > and not inside a partition? > > On 29/01/2020 16:30, Jerry Geis wrote: > > Well after a closer look - Seems like the OLD 8.0 iso image is still on > the > > USB. Not the new 8.1 > > > > I have tried to redo the dd command to copy the 8.1 iso - I get no > errors - > > but it still comes up with the 8.0 > > I then tried to remove the partitions, save and recopy. still same old > boot > > menu. > > > > Is there a trick to write over the UEFI stuff ? > > > > Jerry > > ___ > > CentOS mailing list > > CentOS@centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > > -- > J Martin Rushton MBCS > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 on USB disk
Sorry for the noise... My machine must not be working. I copied the iso to another machine, did the same command as always and worked just fine. not sure what is up with my normal box. Has always worked before. Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 on USB disk
What's your dd command? Are you sure you are writing to the raw disk and not inside a partition? On 29/01/2020 16:30, Jerry Geis wrote: Well after a closer look - Seems like the OLD 8.0 iso image is still on the USB. Not the new 8.1 I have tried to redo the dd command to copy the 8.1 iso - I get no errors - but it still comes up with the 8.0 I then tried to remove the partitions, save and recopy. still same old boot menu. Is there a trick to write over the UEFI stuff ? Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- J Martin Rushton MBCS ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 on USB disk
Well after a closer look - Seems like the OLD 8.0 iso image is still on the USB. Not the new 8.1 I have tried to redo the dd command to copy the 8.1 iso - I get no errors - but it still comes up with the 8.0 I then tried to remove the partitions, save and recopy. still same old boot menu. Is there a trick to write over the UEFI stuff ? Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 8 on USB disk
I did the dd if=CentOS-8.1.1911-x86_64-dvd1.iso of=/dev/sdd to a 16G USB disk then tried to use it on an install. The installer said invalid install media. Any way to verify if the "write" to disk was good ? I got no errors on the dd. I did re-download the iso and did a diff and there was no diff. So I think my iso is OK. Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On Wed, 29 Jan 2020 at 08:16, hw wrote: > > On Wednesday, January 29, 2020 12:38:32 AM CET Stephen John Smoogen wrote: > > On Tue, 28 Jan 2020 at 15:56, hw wrote: > > > > For voice, that > > > > usually means a drop or other ugliness because it is assumed that if > > > > the quality is too bad, the people would just call each other again. > > > > > > That's a funny idea. Phone calls just worked fine and were good quality > > > 25 > > > years ago, and mostly long before that. I have never expected to have to > > > call anyone back because of poor quality in over 40 years, and I'm not > > > going to start to expect that now. > > > > I got that from watching various training videos from the 1940's to > > the 1970's on phone switching systems... and also the basic design of > > how Erlang is programmed and deals with errors. It could be wrong, > > erroneous or crap. However talking to phone people over the years that > > was how they described things. A lot of them would say that a phone > > call could die a billion different ways and it was a miracle it didn't > > happen to everyone every day. It just happened to a couple of people a > > day in different places because everything was coded for redundancy > > and the expectation that it could get bad. That redundancy and > > over-engineering seems to have allowed for the 'worse case they will > > call back' to be a viable option. > > Maybe it took a lot of effort to keep things working, I can't tell. But I can > tell that for over 40 years, there was one single interruption of the phone > line when a major line was damaged due to construction work. Calls weren't > interrupted, either. > 40 years ago if you were in North America or Europe you were relying on large infrastructure laid out by 'Cold War' needs that if a war started the phones from site A to site B would work no matter what. That meant there were all kinds of redundancy in the system.. enough that pretty much every Phone company whether national or private were valued by the amount of copper they had mostly from all this redundancy. When that was no longer a driving factor and various governments were no longer enforcing 'war' regulations on how the phones MUST work.. you saw a lot of lines removed and the copper sold as cash from both private and public phone companies. This was part of the 'peace' dividend that many countries saw in the 1990's where various other infrastructure could be upgraded because it wasn't being held in reserve in case of war. The improvements in mobile phone networks increased this because phone quality was limited to the codecs used in that and you didn't need to string as much copper and could even move to lower quality copper. Optical fibre also got cheaper which allowed for improvements and more dumping of old copper lines. The problem is that phone companies over-dumped and the prices of copper have gone up enough that they can't adequately replace what they need to do now. So they are pushing for more VOIP like solutions to keep their costs down.. but These things go in cycles.. and usually you have to go through a 'everything has gone to hell' before people wake up and realize they needed to invest a certain amount in the infrastructure constantly. So hopefully it will get better someday... -- Stephen J Smoogen. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On Wednesday, January 29, 2020 8:53:50 AM CET Simon Matter via CentOS wrote: > > On Tuesday, January 28, 2020 1:50:57 PM CET Stephen John Smoogen wrote: > >> On Sun, 26 Jan 2020 at 20:45, hw wrote: > >> > > I'm not sure I understand what you are asking. > >> > > >> > It is about VOIP calls via SRTP being interrupted at irregular > >> > >> intervals. > >> > >> > The intervals appear to depend on the time of day: Such phone calls > >> > >> can > >> > >> > last for a duration of about 5--25 minutes during the day to up to 1.5 > >> > hours at around 3am before being interrupted. > >> > >> UDP is called Unreliable Datagram Protocol for a reason. It can be > >> dropped at all kinds of places in between the two users depending on > >> how busy the routers/firewalls between 2 users can be. > > > > How would packets being dropped explain the replay errors and > > authentication > > failures? > > > >> Packets can get > >> out of order or a dozen other things which then relies on the > >> application layer to put the things back in 'order'. > > > > libsrtp seems to have provisions to deal with packets arriving out of > > order. > > > >> For voice, that > >> usually means a drop or other ugliness because it is assumed that if > >> the quality is too bad, the people would just call each other again. > > > > That's a funny idea. Phone calls just worked fine and were good quality > > 25 > > years ago, and mostly long before that. I have never expected to have to > > call > > anyone back because of poor quality in over 40 years, and I'm not going to > > start to expect that now. > > Just wait another 10 or 20 years and everybody will tell you it's normal > and nothing to worry. They won't believe you if you tell them there was a > time long ago when telephony just worked. All things will be a lot worse in 10 or 20 years. > I remember in around 1999, when a lot of companies started to hear about > VoIP and wanted to implement it to save money and welcome the future, I > had lot's of discussion about it in the company I was working back then. > Those who new a bit more from the technology side said this can be done in > a company but not widely as a replacement for (public) telephony > infrastructure. Now that whole countries went all IP, just listen to > police and emergency services what they think about it: only now they > start to realize that having telephony which just works is a thing of the > past! It's still something that just needs to work. And 1999? Maybe it's because this country has kinda detached itself from technology and remains behind further and further, currently about 30 years, but in 1999 nobody has heard of VOIP. That started in 2018, and people expect phone to just work. If anything, it should get better, not worse. > But hey, don't worry, they will fix it with "the Cloud" :-) It only means that we can't do anything anymore. > > It's unacceptable, and it's not feasible, either. For example, try to > > call > > paypal to solve some issue with your account. It can take an hour before > > they > > call you back because everyone is busy. Finally you talk to someone and > > just > > after you explained the problem, the call is interrupted. Good luck > > calling > > the same person back. You won't get anywhere because your next try will > > only > > result in another interrupted call. > > > >> For the most part this works pretty well but all it takes is a > >> firewall to get busy on something else and you have a bunch of UDP > >> packets out of order and people's calls dropping. > > > > VOIP calls are worlds away from what phone calls used to be. Dropping > > calls > > has never been an option and is not an option now. > > Telephony is like operating systems these days: a lot of things improve > but not everything... What has actually improved? In 1999, I could make a phone call whenever I wanted to, and it worked just fine. In 2020, I can't make a phone call at all because it will be interrupted before I'd get anywhere with it and it's just embarrassing. What am I supposed to do? Travel to paypal to talk to someone in person? At least we can still travel, and that is about to change, too. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On Wednesday, January 29, 2020 12:38:32 AM CET Stephen John Smoogen wrote: > On Tue, 28 Jan 2020 at 15:56, hw wrote: > > > For voice, that > > > usually means a drop or other ugliness because it is assumed that if > > > the quality is too bad, the people would just call each other again. > > > > That's a funny idea. Phone calls just worked fine and were good quality > > 25 > > years ago, and mostly long before that. I have never expected to have to > > call anyone back because of poor quality in over 40 years, and I'm not > > going to start to expect that now. > > I got that from watching various training videos from the 1940's to > the 1970's on phone switching systems... and also the basic design of > how Erlang is programmed and deals with errors. It could be wrong, > erroneous or crap. However talking to phone people over the years that > was how they described things. A lot of them would say that a phone > call could die a billion different ways and it was a miracle it didn't > happen to everyone every day. It just happened to a couple of people a > day in different places because everything was coded for redundancy > and the expectation that it could get bad. That redundancy and > over-engineering seems to have allowed for the 'worse case they will > call back' to be a viable option. Maybe it took a lot of effort to keep things working, I can't tell. But I can tell that for over 40 years, there was one single interruption of the phone line when a major line was damaged due to construction work. Calls weren't interrupted, either. That changed with the introduction of mobile phones and got even worse with VOIP. It only means that providers need to figure their stuff out. It doesn't mean that less quality or less reliability would be acceptable --- especially not since we're paying over four times more for it than we used to. > The problem is that if that was real or is still the case... unless > your VOIP solution has as much redundancy.. failure is going to happen > a lot more and in ways that lead to the general experience of the last > 8 VOIP solutions I have been stuck with... dropped calls to Paypal as > you said or sounding like a Dalek if the latency or such just got a > little bad. It's nonetheless not acceptable. We are being forced to become increasingly dependent on what you might call the technology stack, and there isn't much left we could do without it because we don't have any other means and ways of doing things anymore. That involves that the technology is increasingly to required to work better. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On Wednesday, January 29, 2020 10:10:48 AM CET Nataraj wrote: > On 1/28/20 12:39 PM, hw wrote: > > On Tuesday, January 28, 2020 9:00:22 AM CET Nataraj wrote: > >> On 1/26/20 5:44 PM, hw wrote: > >>> On Sunday, January 26, 2020 11:18:36 PM CET Pete Biggs wrote: > First of all - disclaimer - I'm no network specialist, I just read and > am interested in it. I may get things wrong!! > > > Both physical interfaces show the same. But does this mean it's on as > > in > > "rx- checksumming: on" or off as in "tx-checksum-ipv4: off [fixed]"? > > As far as I understand it rx-checksum is the underlying wire > checksumming - and from what I've read about it, disabling that > disables the UDP checksums. > >>> > >>> You mean layer 1 checksumming? Is there such a thing with ethernet? I > >>> think I read something about encoding, when I was trying to understand > >>> what "bandwidth" actually means, being involved in signal transmissions; > >>> and I seem to remember that there was no checksumming involved and it > >>> had > >>> to do with identifying signals as a requirement for the very possibility > >>> to transmit something before anything could be transmitted at all. > >>> > > Assuming that I do not receive packets with invalid UPD checksums, > > then > > the > > packages must be somehow altered and their UPD checksums recalculated > > to > > arrive here. Does bad hardware etc. do that? Why would the UDP > > checksums > > just happen to get recalculated correctly but like randomly without > > intent? > > I'm not sure I understand what you are asking. > >>> > >>> It is about VOIP calls via SRTP being interrupted at irregular > >>> intervals. > >>> The intervals appear to depend on the time of day: Such phone calls can > >>> last for a duration of about 5--25 minutes during the day to up to 1.5 > >>> hours at around 3am before being interrupted. > >> > >> My sense is you may be starting at too low of a level in trying to debug > >> this. > > > > One of the reasons I have to look into it is that it is usually good to > > know more/better. > > > >> I have seen the same kind of problems with my voip service when > >> there is a problem with my Internet connection. When this happens I > >> also see high retransmission rates for tcp connections and other signs > >> of network problem. > > > > How do you monitor such retransmissions to be able to see if and when they > > occur? > > netstat -s | grep -i retrans Cool, that gives a lot of information. Retransmissions are at ~0.012/~0.029 percent on the server/workstation, and the UPD statistics look good. > >> If I check the modem for my Internet connection > >> there are issues with the signal levels and high error rates reported by > >> the modem. If you believe your Internet connection is reliable, then if > >> you run managed switches, check your switch logs for any reported errors. > >> > >> You could try tools like iperf to check for problems on your internal > >> network. You could run some of the basic tools for testing voip > >> performance of your Inetnet connection and if necessary run iperf to a > >> cloud hosted system. > > > > Can you suggest useful tools to analyze VOIP performance, and how do you > > define VOIP performance? > > Well there used to be a number of speedtest like sites that use to > report more accurately , latency, jitter and packet loss. It seems most > of them have now scaled down their output, but you could use ping. mean > deviation is basically jitter. > > I think a few of the tests listed on this site, still work. > > https://getvoip.com/blog/2014/05/12/20-best-voip-speed-test-tools/ Most seem to be test for bandwidth, and none of the VOIP related sites work. Besides, ping times to the US are usually around 200ms, so if there were any results to be abtained, they might be questionable. > There used to be sites that did a calculation for something called MOS > score, which is a measure of expected voice quality based on the > performance of a connection. Don't know if anyone does that anymore. > In the VOIP industry there is fancy/expensive equipment for measuring > end to end performance, but in practice simple ping output with regular > sampling from something like a cron job can tell you alot. VOIP performance comes down to what you might call the human experience. Tools only trying to measure how well data is being transferred aren't going to measure that. The human experience is also subjective and not easy to measure. For example, the network can be perfectly fine, and yet the VOIP performance is total shit when you use a cell phone because their audio output sucks no matter what. What can you expect from a tiny speaker built into a cell phone? > Basically, what you want is that if your phone system relies on your > Internet connection, the pop that your connecting too needs to be > relatively
[CentOS] CentOS-announce Digest, Vol 179, Issue 4
Send CentOS-announce mailing list submissions to centos-annou...@centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-requ...@centos.org You can reach the person managing the list at centos-announce-ow...@centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2020:0157 Important CentOS 6 java-1.8.0-openjdk Security Update (Johnny Hughes) 2. CESA-2020:0199 Critical CentOS 6 openslp Security Update (Johnny Hughes) 3. CESA-2020:0197 Important CentOS 6 python-reportlab Security Update (Johnny Hughes) 4. CEBA-2020:0255 CentOS 6 poppler BugFix Update (Johnny Hughes) 5. CEBA-2020:0257 CentOS 6 libreswan BugFix Update (Johnny Hughes) 6. CEBA-2020:0256 CentOS 6 kernel BugFix Update (Johnny Hughes) 7. CESA-2020:0262 Important CentOS 7 openjpeg2 Security Update (Johnny Hughes) 8. CESA-2020:0195 Important CentOS 7 python-reportlab Security Update (Johnny Hughes) 9. CESA-2020:0203 Important CentOS 7 libarchive Security Update (Johnny Hughes) 10. CESA-2020:0227 Important CentOS 7 sqlite Security Update (Johnny Hughes) 11. CESA-2020:0196 Important CentOS 7 java-1.8.0-openjdk Security Update (Johnny Hughes) 12. CESA-2020:0194 Important CentOS 7 apache-commons-beanutils Security Update (Johnny Hughes) -- Message: 1 Date: Tue, 28 Jan 2020 21:23:05 + From: Johnny Hughes To: centos-annou...@centos.org Subject: [CentOS-announce] CESA-2020:0157 Important CentOS 6 java-1.8.0-openjdk Security Update Message-ID: <20200128212305.ga20...@bstore1.rdu2.centos.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2020:0157 Important Upstream details at : https://access.redhat.com/errata/RHSA-2020:0157 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 160e391e5d12a54047da4ffa40e3797e870e96e64be8161852a6c5bc90f8e71b java-1.8.0-openjdk-1.8.0.242.b07-1.el6_10.i686.rpm 8a073140cdfcbe94589563ec66e923debe94e60581f767336b59e7f800be19f5 java-1.8.0-openjdk-debug-1.8.0.242.b07-1.el6_10.i686.rpm 27d8d994472c8bc17a778effd95bd14fe77a816cdf7b843ddb75e374fa9f3bc4 java-1.8.0-openjdk-demo-1.8.0.242.b07-1.el6_10.i686.rpm 8b16efb098066651e70c4b8dc9aefdf77f783895a50fa5d0eedfd27bf92f9fe7 java-1.8.0-openjdk-demo-debug-1.8.0.242.b07-1.el6_10.i686.rpm 332f068e669b5aa63d6a4bb8c1a6d737f5195174dc2df2d24a175303c3049b86 java-1.8.0-openjdk-devel-1.8.0.242.b07-1.el6_10.i686.rpm a9f6d24d50a529b764a3e85b72a044049307f001a27a06ed0f3b4122bd4b97af java-1.8.0-openjdk-devel-debug-1.8.0.242.b07-1.el6_10.i686.rpm 099f6fc643e8efeddb72116bb5a496ba4e011896eb5fa2eb64f03d68bf83142c java-1.8.0-openjdk-headless-1.8.0.242.b07-1.el6_10.i686.rpm 0d9c2d570953ebb812c0fe5707399d81da1eac03da4f13cd64e2c6bfd57081c9 java-1.8.0-openjdk-headless-debug-1.8.0.242.b07-1.el6_10.i686.rpm ad347216349d88737a257abb1148868b46c9573e9f496adbb1a4697bc5c383b4 java-1.8.0-openjdk-javadoc-1.8.0.242.b07-1.el6_10.noarch.rpm ef223881757a2facd840627b93b32256e7156ecec01c2466c8f9ff61ec078005 java-1.8.0-openjdk-javadoc-debug-1.8.0.242.b07-1.el6_10.noarch.rpm e27fc2105bf01285245c63f8f22d76a0905c81b92c518018525fca09f61eb84f java-1.8.0-openjdk-src-1.8.0.242.b07-1.el6_10.i686.rpm 841bdc7523687b427ba2122d6a288dabcc8d721e9ae500c4193ae4aecae64fb5 java-1.8.0-openjdk-src-debug-1.8.0.242.b07-1.el6_10.i686.rpm x86_64: a747a1f6798d760a1f61aa0eb0a7624f437ded3f24862471725d5a84a1d443f1 java-1.8.0-openjdk-1.8.0.242.b07-1.el6_10.x86_64.rpm a57d85e5299abe89745a6795d026570a780dbd5f67e26d69d35d091e5aa59ab0 java-1.8.0-openjdk-debug-1.8.0.242.b07-1.el6_10.x86_64.rpm a15f0acd7d8e1f9d71880398936ea038dcb0cb6a71a89eef8aa83b31c922ba25 java-1.8.0-openjdk-demo-1.8.0.242.b07-1.el6_10.x86_64.rpm 979e6cb9eb21b4f361965f97eba4ad96da4b3b07f67e05f29eef25b430c8805a java-1.8.0-openjdk-demo-debug-1.8.0.242.b07-1.el6_10.x86_64.rpm 40822874cd2d8a766068776e2fd2d032de16fe9d29aab90a0110cc137f98650b java-1.8.0-openjdk-devel-1.8.0.242.b07-1.el6_10.x86_64.rpm 45b0fe8653c245c9562f3be7f35d8fad4d0f92108ef37656949f982e28cd07ce java-1.8.0-openjdk-devel-debug-1.8.0.242.b07-1.el6_10.x86_64.rpm 1b2fa9dbaf7e91a673c3ebfa89280dc4c141999b9890ebdb41bdaf54fdb78b95 java-1.8.0-openjdk-headless-1.8.0.242.b07-1.el6_10.x86_64.rpm 824fd933f82bb322575360b53e8bbe9b9407c70a2e6b2a9a0304be87e0383209 java-1.8.0-openjdk-headless-debug-1.8.0.242.b07-1.el6_10.x86_64.rpm ad347216349d88737a257abb1148868b46c9573e9f496adbb1a4697bc5c383b4 java-1.8.0-openjdk-javadoc-1.8.0.242.b07-1.el6_10.noarch.rpm ef223881757a2facd840627b93b32256e7156ecec01c2466c8f9ff61ec078005
Re: [CentOS] CentOS 8.1 and NVIDIA support
On Sat, 2020-02-01 at 19:11 -0500, Jerry Geis wrote: > Does CentOS 8.1 support OLDER generate NVIDIA ? > Like NVIDIA Corporation GF119M [GeForce GT 520M] > > I'm looking for hardware acceleration H264 type support. > As far as I know CentOS (i.e. RHEL) never supported accelerated nVidia drivers because they are all closed source. Non-accelerated nVidia drivers are provided by the nouveau packages. The accelerated proprietary drivers are available from rpmfusion, but with old cards you have to be careful which version you install as nVidia are very quick to drop "old" cards from their most recent drivers. There are packages that integrate with yum/dnf to make the version selection automatic. You can, of course, download the drivers directly from nVidia, but you then have to manage the kernel modules yourself when the kernel is updated. P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7: UPD packet checksum verification?
On 1/28/20 12:39 PM, hw wrote: > On Tuesday, January 28, 2020 9:00:22 AM CET Nataraj wrote: >> On 1/26/20 5:44 PM, hw wrote: >>> On Sunday, January 26, 2020 11:18:36 PM CET Pete Biggs wrote: First of all - disclaimer - I'm no network specialist, I just read and am interested in it. I may get things wrong!! > Both physical interfaces show the same. But does this mean it's on as > in > "rx- checksumming: on" or off as in "tx-checksum-ipv4: off [fixed]"? As far as I understand it rx-checksum is the underlying wire checksumming - and from what I've read about it, disabling that disables the UDP checksums. >>> You mean layer 1 checksumming? Is there such a thing with ethernet? I >>> think I read something about encoding, when I was trying to understand >>> what "bandwidth" actually means, being involved in signal transmissions; >>> and I seem to remember that there was no checksumming involved and it had >>> to do with identifying signals as a requirement for the very possibility >>> to transmit something before anything could be transmitted at all. >>> > Assuming that I do not receive packets with invalid UPD checksums, then > the > packages must be somehow altered and their UPD checksums recalculated to > arrive here. Does bad hardware etc. do that? Why would the UDP > checksums > just happen to get recalculated correctly but like randomly without > intent? I'm not sure I understand what you are asking. >>> It is about VOIP calls via SRTP being interrupted at irregular intervals. >>> The intervals appear to depend on the time of day: Such phone calls can >>> last for a duration of about 5--25 minutes during the day to up to 1.5 >>> hours at around 3am before being interrupted. >> My sense is you may be starting at too low of a level in trying to debug >> this. > One of the reasons I have to look into it is that it is usually good to know > more/better. > >> I have seen the same kind of problems with my voip service when >> there is a problem with my Internet connection. When this happens I >> also see high retransmission rates for tcp connections and other signs >> of network problem. > How do you monitor such retransmissions to be able to see if and when they > occur? netstat -s | grep -i retrans > >> If I check the modem for my Internet connection >> there are issues with the signal levels and high error rates reported by >> the modem. If you believe your Internet connection is reliable, then if >> you run managed switches, check your switch logs for any reported errors. >> >> You could try tools like iperf to check for problems on your internal >> network. You could run some of the basic tools for testing voip >> performance of your Inetnet connection and if necessary run iperf to a >> cloud hosted system. > Can you suggest useful tools to analyze VOIP performance, and how do you > define VOIP performance? Well there used to be a number of speedtest like sites that use to report more accurately , latency, jitter and packet loss. It seems most of them have now scaled down their output, but you could use ping. mean deviation is basically jitter. I think a few of the tests listed on this site, still work. https://getvoip.com/blog/2014/05/12/20-best-voip-speed-test-tools/ There used to be sites that did a calculation for something called MOS score, which is a measure of expected voice quality based on the performance of a connection. Don't know if anyone does that anymore. In the VOIP industry there is fancy/expensive equipment for measuring end to end performance, but in practice simple ping output with regular sampling from something like a cron job can tell you alot. Basically, what you want is that if your phone system relies on your Internet connection, the pop that your connecting too needs to be relatively close and have minimal packet loss and similar latency/jitter characteristics on both the up/down stream. Generally that is not too hard to find these days, but if the Internet connectivity to your voip pop takes a route half way across the country over the Internet, that's not it. I have one of the lowest cost voip providers, voip.ms, and I find the voip quality to be excellent and call drop rate to be low except when I have problems with my Internet provider. > > The performance is kinda acceptable as long as the calls are not interrupted. > > It's still worlds apart from what it used to be 25 years ago, before VOIP was > used. Back then, you never had to worry that calls could be interrupted or > that you couldn't hear someone or that you couldn't have a conversation > because the latency makes it impossible. You could just talk to someone on a > phone, like it should be. Nowadays, we get to pay 10 times as much and more, > plus all the expensive hardware, and it still doesn't work right and doesn't > even come close. Well if your relying on the Internet, you are essentially
Re: [CentOS] CentOS 8.1 and NVIDIA support
Il 02/02/20 01:11, Jerry Geis ha scritto: Does CentOS 8.1 support OLDER generate NVIDIA ? Like NVIDIA Corporation GF119M [GeForce GT 520M] I'm looking for hardware acceleration H264 type support. Thanks, Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Hi Jerry, I don't know if your card is supported natively considering it an old model. The default module for NVIDIA GPU is nouveau but I remove it due to low performances. I have a 1050ti and currently using rpmfusion-nonfree for NVIDIA driver to avoid problem every kernel update using NVIDIA "package". Try to install rpmfusion packages and try. Hope that helps. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
