similar to: over/underestimating expected packet loss

Displaying 20 results from an estimated 30000 matches similar to: "over/underestimating expected packet loss"

2013 Jul 27
1
repacketizing unrelated frames
Hi Jean-Marc, I looked at that but importantly these streams need to remain absolutely independent, Further they may have been encoded at some previous time. So my question stands. Thanks, Marc On Jul 26, 2013, at 9:10 PMEDT, Jean-Marc Valin wrote: > Hi Marc, > > I recommend you have a look at the multistream API and how we use it for > surround in the Ogg Opus draft. Sounds
2015 Apr 14
3
behavior of as.integer("5000000000")
On 04/13/2015 11:32 PM, Martin Maechler wrote: > >> Hi, >> > as.integer("5000000000") >> [1] 2147483647 >> Warning message: >> inaccurate integer conversion in coercion > >> > as.integer("-5000000000") >> [1] NA >> Warning message: >> inaccurate integer conversion in coercion >
2015 Apr 17
1
behavior of as.integer("5000000000")
>>>>> Martin Maechler <maechler at lynne.stat.math.ethz.ch> >>>>> on Fri, 17 Apr 2015 15:49:35 +0200 writes: >>>>> Herv? Pag?s <hpages at fredhutch.org> >>>>> on Mon, 13 Apr 2015 23:36:14 -0700 writes: >> On 04/13/2015 11:32 PM, Martin Maechler wrote: >>> >>>> Hi,
2015 Apr 14
3
behavior of as.integer("5000000000")
Hi, > as.integer("5000000000") [1] 2147483647 Warning message: inaccurate integer conversion in coercion > as.integer("-5000000000") [1] NA Warning message: inaccurate integer conversion in coercion Is this a bug or a feature? The man page suggests it's the latter: ?as.integer? attempts to coerce its argument to be of integer type.
2009 May 06
2
convert large integers to hex
Hi, I'm wondering if someone has solved the problem of converting very large integers to hex. I know about format.hexmode and as.hexmode, but these rely on integers. The numbers I'm working with are overflowing and losing precision. Here's an example: x <- "6595137340052185552" # stored as character as.integer(x) # warning about inaccurate conversion
2009 Aug 13
1
power.t.test (PR#13891)
Full_Name: Michael J. Lew Version: R version 2.9.1 (2009-06-26) OS: OS X Submission from: (NULL) (210.49.195.149) The default function power.t.test gives inaccurate values, particularly with large sig.level. There are two reasons for me to propose that power.t.test is inaccurate: 1. When sig.level approaches 1, so should the power. However,
2013 Jul 26
2
repacketizing unrelated frames
I can't quite figure this out from looking at the repacketizer code. Let's say I have 4 separate stereo streams (say from an 8 channel converter) and want to transmit them somewhere in one stream e.g. RTP or the like. (assuming, custom format if necessary) So could I merge 4 packets with the repacketizer, TX the merged packets, on the other side RX them then split them with the
1999 Jun 09
2
summary gives inaccurate data
Hi, using R64.1 the summary function for simple statistics of a vector gives inaccurate results for the maximum. Example: summary(c(123456,1,2,3)) gives : Min. 1st Qu. Median Mean 3rd Qu. Max. 1.00 1.75 2.50 30870.00 30870.00 123500.00 The Max value ist wrong in a mathematical sense. I've tried with S-Plus, it gives the same result, but this seems
2015 Dec 03
6
7.2 kernel panic on boot
Am 03.12.2015 um 11:08 schrieb Greg Lindahl <lindahl at pbm.com>: > I wanted to help you by making sure that you were on the most recent > version, but, looking at the Centos.org website I was unable to figure > out if 7.2 was the tip. 7.1503? Is that 7.2? Beats me. CentOS 7.1511 (aka '7.2') not yet released ... > https://wiki.centos.org/Download appears to say that
2008 Aug 27
3
Packet Loss question
Hello all, I know that SPEEX has a mechanism to handle packet loss. I see there is some handling for packet loss implemented in speexdec. I want to know, if in my own application should i also implement such packet loss handling or is it taken care of within the decoder? I want to test my SPEEX application for GNU Radio for some packet loss,if i just simulate a packet loss mechanism, will it work
2004 Aug 26
4
PLC (Packet loss cancel) questions
Hello I've been using VoIP over a not so reliable net: I usually get a 5% to 10% packet loss and a very high jitter. I tried several codecs and parameters, and the only thing left to test is PLC (Packet Loss Cancellement). Have the astesrisk and digium people implemented PLC?, Are they implmementing it now? and, if not, Where can i find an implementation? Thanks in advance -- Jorge
2014 May 20
2
packet loss
Hi, Something strange is happening at my place: I have lots of packet loss in my tinc vpn. Network layout: laptop --- wifi --- other pc ping from laptop to other pc OUTSIDE tinc: 0% packet loss ping from laptop to other pc VIA tinc: 50% packet loss What could be the cause of that? Folkert van Heusden -- Always wondered what the latency of your webserver is? Or how much more latency you
2007 Oct 22
2
NAT traversal packet loss measurement
How can one measure the effect of NAT traversal packet loss? We currently have no solution for NAT traversal for our SIP clients. There is no doubt that packets are getting lost. What is not clear is how much damage this does. On the face of it, everything seems fine. Could this be so? Perhaps we're suffering a degradation in quality or our call setup times could be improved. How can we
2007 Oct 11
1
[Fwd: Re: pt inaccurate when x is close to 0 (PR#9945)]
Here's a contribution from Ian Smith that got bounced from the list. -------- Original Message -------- Subject: Re: [Rd] pt inaccurate when x is close to 0 (PR#9945) Date: Thu, 11 Oct 2007 06:02:43 -0400 From: iandjmsmith at aol.com To: murdoch at stats.uwo.ca Duncan, I tried sending the rest of this to R-devel but it was rejected as spam, hence the personal e-mail. R calculates the pt
2015 Dec 03
4
7.2 kernel panic on boot
Am 03.12.2015 um 11:39 schrieb Greg Lindahl <lindahl at pbm.com>: > On Thu, Dec 03, 2015 at 11:28:10AM +0100, Leon Fauster wrote: >> Am 03.12.2015 um 11:08 schrieb Greg Lindahl <lindahl at pbm.com>: >>> I wanted to help you by making sure that you were on the most recent >>> version, but, looking at the Centos.org website I was unable to figure >>>
2015 Dec 03
4
7.2 kernel panic on boot
Am 03.12.2015 um 19:35 schrieb Greg Lindahl <lindahl at pbm.com>: > On Thu, Dec 03, 2015 at 12:26:08PM +0100, Leon Fauster wrote: >>> >>> And the way I'd figure this out from the centos website is? > > Note that I was asking about the release numbering, not the release > itself. And while you're suggesting where I could find out more or > take part
2015 Sep 02
3
groupadd failure
Sorry, I didn't read what you said carefully enough -- it's trying to create a system group. Still, looking inside of /etc/group to see what system groups already exist is probably a good idea. On Wed, Sep 02, 2015 at 02:19:51PM -0700, Greg Lindahl wrote: > The groupadd manpage gives this clue: > > The default is to use the smallest ID value greater than or equal to >
2015 Dec 03
1
7.2 kernel panic on boot
On Thu, Dec 3, 2015 at 5:39 AM, Greg Lindahl <lindahl at pbm.com> wrote: > On Thu, Dec 03, 2015 at 11:28:10AM +0100, Leon Fauster wrote: > > Am 03.12.2015 um 11:08 schrieb Greg Lindahl <lindahl at pbm.com>: > > > I wanted to help you by making sure that you were on the most recent > > > version, but, looking at the Centos.org website I was unable to figure
2009 Aug 02
1
Inaccurate complex arithmetic of R (Matlab is accurate)
Dear All, Hans Borchers and I have been trying to compute "exact" derivatives in R using the idea of complex-step derivatives that Hans has proposed. This is a really, really cool idea. It gives "exact" derivatives with only a minimal effort (same as that involved in computing first-order forward-difference derivative). Unfortunately, we cannot implement this in R as the
2015 Dec 03
3
7.2 kernel panic on boot
Valeri Galtsev wrote: > > On Thu, December 3, 2015 4:28 am, Leon Fauster wrote: >> Am 03.12.2015 um 11:08 schrieb Greg Lindahl <lindahl at pbm.com>: >>> I wanted to help you by making sure that you were on the most recent >>> version, but, looking at the Centos.org website I was unable to figure >>> out if 7.2 was the tip. 7.1503? Is that 7.2? Beats me.