Ahh of course, yes i researched on tweaking mina settings, and went into low level nic/network stuff which is way over my head. If 256k is the max then I guess we could leave it at that, we are using windows 2003 servers with gigabit nics.
Luke Hubbard wrote: > Glad its working well for you, > > I'm happy it turned out to be something quite simple once we had > isolated what was happening. > > The settings are in red5-core.xml : sendBufferSize, etc > I set it to 256k which sounds like enought to me, and I read its the > max on linux. > > You can read more about the tcp buffer here.. > http://www.onlamp.com/pub/a/onlamp/2005/11/17/tcp_tuning.html > > Please do have try out different settings and report what you find optimal. > > - Luke > > > On 4/13/07, Dan Rossi <[EMAIL PROTECTED]> wrote: > >> Hi luke its the weekend now but i just tested the streaming, it started >> str8 away and kept a buffer length of 10 seconds, which is on par with >> wowza. FMS seems to get much more, but i was testing this on a fairly >> standard ADSL conn over a wireless network, will test wired from a 24MB >> adsl later. But whatever you did freakin nailed it mate, i knew it all >> along it was mina settings, i tried to research some of it but it was >> too hard. >> >> Can you please document again which settings were changed and where, so >> i can try and play with those settings, i guess ill just give it the >> most maximum level it can go ? It seems mina was shaping the packets or >> something ? >> >> >> Luke Hubbard wrote: >> >>> Nope that seems like a unrelated issue.- >>> I will try to have a look into that though asap. >>> >>> - Luke >>> >>> On 4/13/07, Dan Rossi <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Will this fix the reason why the connection drops out as soon as >>>> playback starts ? I havent to set the timeout to 10000000 currently. >>>> >>>> Dan Rossi wrote: >>>> >>>> >>>>> Ok thanks, ill give this a try again today. >>>>> >>>>> Luke Hubbard wrote: >>>>> >>>>> >>>>> >>>>>> After playing with some settings I think ive fixed it, check out the >>>>>> latest trunk. >>>>>> Im able to stream from the states to thailand with 2s buffer without >>>>>> any underruns. Joachims new buffer code rocks :) The buffer was within >>>>>> 20ms of the set value. >>>>>> >>>>>> There are some new settings in red5-core.xml. >>>>>> >>>>>> <property name="sessionConfig.receiveBufferSize" value="65536" /><!-- >>>>>> 64k --> >>>>>> <property name="sessionConfig.sendBufferSize" value="271360" /><!-- 256k >>>>>> --> >>>>>> <property name="sessionConfig.tcpNoDelay" value="true" /> >>>>>> >>>>>> Thanks for reporting this problem. >>>>>> >>>>>> Regards, >>>>>> Luke >>>>>> >>>>>> On 4/12/07, Luke Hubbard <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Lets get to the bottom of this one once and for all. I'm fairly sure >>>>>>> its a network issue, probably something to do with mina. I've checked >>>>>>> the server when its streaming and as far as it is aware its actually >>>>>>> sending the file fast enough. So for some reason slowing down going >>>>>>> over the network. But this is NOT a network issue. >>>>>>> >>>>>>> When running those swfs you send, I get 26-32kbps on red5 and >>>>>>> 62-65kbps on wowza. >>>>>>> Clearly there is a problem.. with red5, mina, and rtmp. As far as I'm >>>>>>> aware wowza also uses mina so I dont think problem is mina but perhaps >>>>>>> something with our settings or the size of the packets we are sending. >>>>>>> >>>>>>> Things I've tried so far.. >>>>>>> >>>>>>> tcp no delay off makes no difference. >>>>>>> tried with rtmp and the problem is not there which tells us it must be >>>>>>> a mina issue. >>>>>>> >>>>>>> Ideas and suggestions of things we can try to fix this?? I will keep >>>>>>> trying things. >>>>>>> >>>>>>> Regards, >>>>>>> Luke >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/12/07, Dan Rossi <[EMAIL PROTECTED]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> http://69.42.91.84:5080/RED5_WWW2.swf >>>>>>>> >>>>>>>> http://69.42.91.84:5080/WOWZA_WWW2.swf >>>>>>>> >>>>>>>> could be different in various locations but click the video centre for >>>>>>>> the stats, if you see a big difference in the buffer length between the >>>>>>>> two its a good start to work out the problem I guess ? From my >>>>>>>> observation the others "push" extra bits somehow to keep it up to >>>>>>>> speed. >>>>>>>> >>>>>>>> There is absolutely nothing wrong with our connection then or even too >>>>>>>> much latency which is about 200ms from the looks of it. >>>>>>>> >>>>>>>> Dan Rossi wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Im really unsure whats the maximum video bitrate we could be streaming >>>>>>>>> without a problem, as of now it seems a 180k video is the maximum >>>>>>>>> without the buffer length issues. >>>>>>>>> >>>>>>>>> Back to the wowza comparison, im playing a 512k stream perfect with >>>>>>>>> 9-10 >>>>>>>>> second buffer length, starts straight away, in red5 the same clip >>>>>>>>> drops >>>>>>>>> the ball in pretty much immediately, and the buffer length decreases >>>>>>>>> every 3 seconds which is on par with the 300k clip,so its not reducing >>>>>>>>> faster than the 300k clip. >>>>>>>>> >>>>>>>>> A 780k stream wowza is yet again able to play fine, keeps a length of >>>>>>>>> 10 >>>>>>>>> seconds, red5 rebuffers every 10 seconds. >>>>>>>>> >>>>>>>>> Here is my ping status to our server >>>>>>>>> >>>>>>>>> PING 69.42.93.22 (69.42.93.22): 56 data bytes >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=0 ttl=112 time=255.277 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=1 ttl=112 time=255.172 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=2 ttl=112 time=255.172 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=3 ttl=112 time=255.663 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=4 ttl=112 time=255.009 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=5 ttl=112 time=254.927 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=6 ttl=112 time=255.430 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=7 ttl=112 time=255.199 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=8 ttl=112 time=255.265 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=9 ttl=112 time=255.086 ms >>>>>>>>> 64 bytes from 69.42.93.22: icmp_seq=10 ttl=112 time=255.159 ms >>>>>>>>> ^C >>>>>>>>> --- 69.42.93.22 ping statistics --- >>>>>>>>> 11 packets transmitted, 11 packets received, 0% packet loss >>>>>>>>> round-trip min/avg/max/stddev = 254.927/255.214/255.663/0.191 ms >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan Rossi wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I just tried a 38K clip and obviouslly it stayed at 8 second buffer >>>>>>>>>> length, not sure if anyone has read my comparisons both FMS and wowza >>>>>>>>>> "push" extra into the buffer it increases more than the buffer time, >>>>>>>>>> when the length goes back to the buffer time in pushes it back to >>>>>>>>>> about >>>>>>>>>> double the buffer length. red5 seems to just keep it at the buffer >>>>>>>>>> time, >>>>>>>>>> >>>>>>>>>> I just tried a 180K clip, and the length increases but only slightly. >>>>>>>>>> Some things might have been fixed because on a 1MB and 5MB adsl >>>>>>>>>> connection it was not possible to play either. >>>>>>>>>> >>>>>>>>>> I just tried a non red5 demo video, which was a 300k video, there is >>>>>>>>>> a >>>>>>>>>> pattern forming here, it degrades every 10 seconds or so. >>>>>>>>>> >>>>>>>>>> I ran a bandwidth test on cnet and says our conn is 156kbps, >>>>>>>>>> >>>>>>>>>> http://reviews.cnet.com/7009-7254_7-0.html?CType=2278&ac=2&ISPID=&ISPNAME=&&kbps=156 >>>>>>>>>> >>>>>>>>>> our adsl conn is 8MB but im not sure what it syncs at does this sound >>>>>>>>>> about right ? When i test on a 5MB syncing adsl connection it cannot >>>>>>>>>> play anything larger than 180 either. >>>>>>>>>> >>>>>>>>>> We can play windows media 780k streams fine, its setup with http >>>>>>>>>> protocol streaming though, but isnt progressive download or would it >>>>>>>>>> be >>>>>>>>>> partially ? >>>>>>>>>> >>>>>>>>>> I ran our bwchecker again, the numbers are much lower than before. Im >>>>>>>>>> not really sure though how to match these values to video bitrate >>>>>>>>>> numbers, i know i sound retarded, why would cnet show our conn to be >>>>>>>>>> 156kbps when these numbers are showing anything between 300-2000 >>>>>>>>>> KBdown, >>>>>>>>>> are these kbits or kbyte ? From the code it seems the KBdown is in >>>>>>>>>> fact >>>>>>>>>> kbit per second, so should match the bitrate of the videos >>>>>>>>>> >>>>>>>>>> deltaDown = (endStats.getWrittenBytes() - >>>>>>>>>> beginningValues.get("b_down")) >>>>>>>>>> * 8 / 1000; // bytes to kbits >>>>>>>>>> deltaTime = ((now - beginningValues.get("time")) - (latency * >>>>>>>>>> cumLatency)) / 1000; // total dl time - latency for each packet sent >>>>>>>>>> in secs >>>>>>>>>> >>>>>>>>>> if (deltaTime <= 0) { >>>>>>>>>> deltaTime = (now - beginningValues.get("time")) / >>>>>>>>>> 1000; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> kbitDown = Math.round(deltaDown / deltaTime); // kbits / sec >>>>>>>>>> >>>>>>>>>> log.info("onBWDone: kbitDown = " + kbitDown + ", deltaDown= " + >>>>>>>>>> deltaDown + ", deltaTime = " + deltaTime + ", latency = " + >>>>>>>>>> this.latency); >>>>>>>>>> >>>>>>>>>> this.callBWDone(this.kbitDown, this.deltaDown, this.deltaTime, >>>>>>>>>> this.latency); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> KBDown: 681 Delta Down: 1047 Delta Time: 1.538 Latency: 238 >>>>>>>>>> KBDown: 593 Delta Down: 1047 Delta Time: 1.765 Latency: 239 >>>>>>>>>> KBDown: 308 Delta Down: 176 Delta Time: 0.572 Latency: 250 >>>>>>>>>> KBDown: 440 Delta Down: 1047 Delta Time: 2.379 Latency: 235 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Dan Rossi wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi mate yes you were saying, its always been a problem here and >>>>>>>>>>> doing my >>>>>>>>>>> head in :) >>>>>>>>>>> >>>>>>>>>>> rtmp://69.42.93.22/oflaDemo >>>>>>>>>>> >>>>>>>>>>> i had to make that change in the core to increase the timeout to >>>>>>>>>>> 1000000 >>>>>>>>>>> or else id get disconnected. The oflademo swf is definitely doing >>>>>>>>>>> exactly the same thing as my flex player. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> joseph wamicha wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hey Dan, >>>>>>>>>>>> >>>>>>>>>>>> I'm having exactly the same problems. It works in LAN but fails. >>>>>>>>>>>> I'm >>>>>>>>>>>> located in Nairobi and our networks are poor and have a lot of >>>>>>>>>>>> latencies. It was working previously so I'm guessing it's something >>>>>>>>>>>> related to the latency. It used to work pretty well before but now >>>>>>>>>>>> plays for some seconds and then stops. I'll probably do more tests >>>>>>>>>>>> later. >>>>>>>>>>>> >>>>>>>>>>>> On 4/12/07, *Dan Rossi* <[EMAIL PROTECTED] >>>>>>>>>>>> <mailto:[EMAIL PROTECTED]>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Kinda odd really, here is what the bandwdith detection app >>>>>>>>>>>> returns, >>>>>>>>>>>> although im not really sure how to make use of the data yet, i >>>>>>>>>>>> refresh a >>>>>>>>>>>> few times as it seems to return inconcistant data, we should be >>>>>>>>>>>> able to >>>>>>>>>>>> play the 400k star wars trailer fine on this connection really, >>>>>>>>>>>> Ill try >>>>>>>>>>>> a very low bitrate video but im pretty sure its got nothing to >>>>>>>>>>>> do with >>>>>>>>>>>> bits, but how its pushed out. >>>>>>>>>>>> >>>>>>>>>>>> KBDown: 1497 Delta Down: 1918 Delta Time: 1.281 Latency: 45 >>>>>>>>>>>> KBDown: 1803 Delta Down: 1918 Delta Time: 1.064 Latency: 52 >>>>>>>>>>>> KBDown: 149 Delta Down: 176 Delta Time: 1.185 Latency: 60 >>>>>>>>>>>> KBDown: 1258 Delta Down: 1047 Delta Time: 0.832 Latency: 93 >>>>>>>>>>>> >>>>>>>>>>>> Dan Rossi wrote: >>>>>>>>>>>> > Apologies, i just tried my flex player in a standalone flash >>>>>>>>>>>> and it >>>>>>>>>>>> > plays right away, this seem to be some wierd thing debugging >>>>>>>>>>>> in flex >>>>>>>>>>>> > maybe on the pc ? Its still dropping the buffer length after >>>>>>>>>>>> each buffer >>>>>>>>>>>> > so every 8 seconds it rebuffers. I was alerted that it was >>>>>>>>>>>> fixed :\ >>>>>>>>>>>> > >>>>>>>>>>>> > Dan Rossi wrote: >>>>>>>>>>>> > >>>>>>>>>>>> >> Hi i set the setting a few more zeros and finally wanted to >>>>>>>>>>>> play, so its >>>>>>>>>>>> >> dropping the connection not soon after its playing because >>>>>>>>>>>> it >>>>>>>>>>>> thinks its >>>>>>>>>>>> >> timing out ?. >>>>>>>>>>>> >> >>>>>>>>>>>> >> It is however doing exactly as before, buffers, begins to >>>>>>>>>>>> play, >>>>>>>>>>>> seeks to >>>>>>>>>>>> >> 8 seconds, stops, buffers, plays, then buffer length drops >>>>>>>>>>>> down to 0 >>>>>>>>>>>> >> not soon after. This buffer problem has never really >>>>>>>>>>>> managed to >>>>>>>>>>>> work. >>>>>>>>>>>> >> >>>>>>>>>>>> >> <bean id="rtmpMinaConnection" scope="prototype" >>>>>>>>>>>> >> class="org.red5.server.net.rtmp.RTMPMinaConnection"> >>>>>>>>>>>> >> <property name="keepAliveInterval" >>>>>>>>>>>> value="100000000" /> >>>>>>>>>>>> >> </bean> >>>>>>>>>>>> >> >>>>>>>>>>>> >> Is this correct ? >>>>>>>>>>>> >> >>>>>>>>>>>> >> Joachim Bauch wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >>> Hi Dan, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Dan Rossi schrieb: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>>> Hi ive updated trunk to check out if the latency issue has >>>>>>>>>>>> been removed >>>>>>>>>>>> >>>> however no, when it reaches 7 seconds into the stream the >>>>>>>>>>>> playback >>>>>>>>>>>> >>>> stops, and there is no error returned. Any ideas ? >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>> can't reproduce this. Using ofla_demo.swf everything works >>>>>>>>>>>> just fine. >>>>>>>>>>>> >>> You could try changing the "keepAliveInterval" property in >>>>>>>>>>>> the >>>>>>>>>>>> bean >>>>>>>>>>>> >>> "rtmpMinaConnection" in "red5-core.xml" to check if your >>>>>>>>>>>> client gets >>>>>>>>>>>> >>> disconnected by the ghost detection code. >>>>>>>>>>>> >>> The ghost detection code is something we will be working on >>>>>>>>>>>> for the >>>>>>>>>>>> >>> 0.6 final release. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Joachim >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> _______________________________________________ >>>>>>>>>>>> >>> Red5 mailing list >>>>>>>>>>>> >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>>>>>>> >>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> >> _______________________________________________ >>>>>>>>>>>> >> Red5 mailing list >>>>>>>>>>>> >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>>>>>>> >> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>> > Red5 mailing list >>>>>>>>>>>> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>>>>>>> > http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Red5 mailing list >>>>>>>>>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> C is forever. >>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Red5 mailing list >>>>>>>>>>>> [EMAIL PROTECTED] >>>>>>>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Red5 mailing list >>>>>>>>>>> [EMAIL PROTECTED] >>>>>>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Red5 mailing list >>>>>>>>>> [EMAIL PROTECTED] >>>>>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Red5 mailing list >>>>>>>>> [EMAIL PROTECTED] >>>>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Red5 mailing list >>>>>>>> [EMAIL PROTECTED] >>>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Luke Hubbard >>>>>>> codegent | coding for the people >>>>>>> http://www.codegent.com >>>>>>> >>>>>>> NMA Top 100 Interactive Agencies - Ones to watch! >>>>>>> http://www.codegent.com/top100/ >>>>>>> >>>>>>> want to know more? >>>>>>> http://www.codegent.com/showreel/ >>>>>>> >>>>>>> This e-mail may contain information which is privileged, confidential >>>>>>> and protected from disclosure. If you are not the intended recipient >>>>>>> of this e-mail, or any part of it, please delete this email and any >>>>>>> attachments immediately on receipt. You should not disclose the >>>>>>> contents to any other person or take copies. Any views expressed in >>>>>>> this message are those of the individual sender, except where the >>>>>>> sender specifically states them to be the views of codegent limited. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Red5 mailing list >>>>> [EMAIL PROTECTED] >>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Red5 mailing list >>>> [EMAIL PROTECTED] >>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Red5 mailing list >> [EMAIL PROTECTED] >> http://osflash.org/mailman/listinfo/red5_osflash.org >> >> > > > _______________________________________________ Red5 mailing list [EMAIL PROTECTED] http://osflash.org/mailman/listinfo/red5_osflash.org
