Mick <michaelkintz...@gmail.com> [15-07-29 20:16]: > On Wednesday 29 Jul 2015 18:38:07 James wrote: > > <Meino.Cramer <at> gmx.de> writes: > > > J. Roeleveld <joost <at> antarean.org> [15-07-29 16:38]: > > > > On Wednesday, July 29, 2015 05:18:25 AM Meino.Cramer <at> gmx.de wrote: > > > > > > > > Is this speed between both machines? Or to the internet? > > > > Joost is exactly correct here. Test the links one connection at > > a time, not just all a once. You'll be able to get a 'sit of pants' feeling > > about the capabilities on each link (between devices). There are many many > > issues so let's first characterize each link by the bandwith. > > > > > > On ethernet interfaces this is a really cool tool:: > > > > net-analyzer/bwmon and net-analyzer/nbwmon > > > > > I fired up create_ip like this (just for testing and haveing at least > > > ONE experienced succes with this Wifi stuff...): > > > > > > create_ap wlan0 eth1 <name> <pass> > > > > > > How can I check for the type of WIFI after the connection has been > > > established? > > > > 'ip link' and 'netstat -nr' are a good start. Later on we'll get > > you some gui tools and a monitoring software (a ton of options)... > > > > > USB is USB 2.0 > > > > > > The speed is measured by conky, which reads the transfer rate at eth0. > > > At that tome, the tablet was getting a greater piece of tar archive > > > (LInux for Android) and no other traffic other than this was there. > > > The DSL was by far not saturated. > > > > Really? How do you know. It take lots of experimenting and testing > > and data collection over time to figure our exactly what your > > ISp(s) are doing. Usually several ISPs are in a link until you hit > > a 'peering point' > > > > 'net-analyzer/traceroute' > > > > is your friend. At some point the ISPs will block traceroute info.... > > > > > So physically it is the speed of the internet but logically it is > > > nearly identical to what happens at the Wifi interface (I think). > > > I will check for an app which displays the speed measured on the > > > tablets interface... > > > > This is a very, very complicated issue. ISP(s) use devices to deliver > > and partition bandwidth; some with an incredible level of control > > (granularity). For instances they can 'port constrict' a service > > or a route to an endpoint or any number of things. So first fully > > study (characterize) the behavior of the links (connnections between > > devices) that you manage and develop that 'seat of pants' feeling about the > > network segments you manage. Then start sniffing up the outside folks, > > as best you can with the tools in the portage tree.....(many). > > > > > > You need to also understand that Usb has it's own problems, protocols and > > issues depending on how it was implemented by the chipsets use and the > > firmware inside the product. Other protocol (latencies and such) are > > layered on top of that. Ju are 'full stack' wheelin and dealing as soon > > as your run gui apps across that link.........brau. > > > > > Best regards, > > > Meino > > > > ttfn, > > Always your pal! > > James > > It could also be that the tablet has a slow write speed, if you were > downloading a file. Can you stream a video instead and see if this is > achieving a higher speed? > > -- > Regards, > Mick
Hi Mick, thanks for your infos! :) yupp! Works like a charm (video streaming)! It was a default setting in create_ap which seems to select an old procotol based on drums and morse code... ;) After adding --ieee80211n to the commandline the problem vanished and the data transfer rate jumps up to a level, where the limiting device was my DSL provider :) I am happy with that now ! Best regards, Meino
