Hi all, Just a little addendum on 'catchups' that we were experiencing (and finally solved):
Our IP uses FreeBSD servers, and our particular server has massive resources, lots of CPU power, 2.5 GB RAM, and abundant Bandwidth - 5 TB. So, tracking down these devils was a real nightmare. What gave use the clue to our problem was the slight differences in actual time that the server displayed. We noticed that it slowly began to drift from a few ms to a few minutes. When we finally looked into it, we found that FreeBSD resyncs server-time from an external source using ntpd. Essentially, the server OS had to be re-compiled properly to allow users to update for time-drift. Once this issue was attended to, the catchups have all but disappeared -- finally. A rather obtuse problem/solution. However, it might be worth checking for actual time-drift, and eliminating that posibility since this will affect liquidsoap performance. Hope this might help someone out there in LS Land :) kronos On Tue, 18 Jun 2013 23:17:38 -0400, David Baelde <[email protected]> wrote: > Hi guys, > > These issues are hard to fix, as they depend on a lot of factors. We > should keep watching out for what liquidsoap could do better, but so > far I don't see how the tool itself could help here. > > Instead, I thought I would do a quick recap on what overruns/underruns > and "we need to catchup" are and what causes them. You may know all > this already, and it might not help much because in the end anything > can be caused by anything. In a sense, all it says is that liquidsoap > can't do any better on that... please contradict me on that :p > > The catchup thing is when liquidsoap did not manage to compute its > stream fast enough for sending on time. In my experience this is > caused by lack of CPU, so I'd advise to look this way. It could be > that a latency on the filesystem or network is making things late, but > we are trying to minimize this kind of interference because streaming > on time is the priority. The bottom line is look for CPU first, but if > you think you've spotted another cause let us know so we can discuss > potential solutions. > > A buffer underrun could be caused by a network lag, a slow source, or > liquidsoap being too slow on something else to read from the source > and fill its buffer. A buffer overrun could also be caused by > liquidsoap being too slow to consume the buffer. (A typical situation > where you get lots of overruns is if you don't always read a live > stream, the solution is to put a dummy output on that stream so that > it always gets consumed.) However, it could also be that the source is > too fast. This happens: not all computers have the same clock, and not > all streaming software deal with time in the same way. If you have > relatively rare and periodic overruns that don't seem to be correlated > with CPU spikes or catchup, this is probably the cause. > > Cheers, > > David > > On Mon, Jun 17, 2013 at 8:53 AM, Akos Veres <[email protected]> wrote: >> I'm experiencing the same issues every day, didn't quite manage to fix >> it. I >> had bigger drouputs, like streams actually stopping, then I stopped the >> skip_blank feature thinking my CPU is under heavy dosage, it did make >> the >> stream drops stop, but the overrun is still there. >> >> Any fix is welcome. >> >> Best regards, >> Ákos Veres >> >> _____________________________________________ >> http://akos.me - A little about me. >> >> >> On Fri, Jun 14, 2013 at 6:15 PM, Alexander Schremmer >> <[email protected]> >> wrote: >>> >>> On 12.06.2013 10:20, Alexander Schremmer wrote: >>> >>> >>> Are the times when this problem happens consistent? Try setting the >>> >>> the >>> >>> CPU priority of Liquidsoap to the max and see if that helps: >>> >> >>> >> No, but the other processes might demand resources irregularly. >>> >> >>> >> I will give it a boost to -5 (-19 sounds a bit hazardous given that >>> I >>> >> have seen LS eating 100% in the past). >>> > >>> > Now I have another issue left: after I set a metadata item via >>> telnet, I >>> > get spurious skips that look like this in the logs: >>> > >>> >> 2013/06/12 10:16:24 [server:3] New client: localhost. >>> >> 2013/06/12 10:16:24 [server:3] Client localhost disconnected without >>> >> saying goodbye..! >>> >> 2013/06/12 10:16:26 [clock.wallclock_main:2] We must catchup 1.05 >>> >> seconds! >>> > >>> > And the audio skips for maybe 300 ms in the stream when listening. >>> What >>> > could be the reason? Interestingly, it always happens shortly after >>> > these telnet connections but never in a song. >>> >>> And today we got 90 seconds outage because of a cascade of problems in >>> Liquidsoap. It started with the error message "Buffer overrun: Dropping >>> 0.03s." and ended with both icecast sinks reconnecting, and then it >>> needed still 80 seconds till they started working. >>> Anybody an idea what could have caused this? >>> >>> Kind regards, >>> Alexander >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> _______________________________________________ >>> Savonet-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/savonet-users >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Savonet-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/savonet-users >> > > > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
