Hi Paul,

With Nstreme, at least as I use it with polling, there is not a way to see retransmits. I mentioned this in my previous post:

You can quantify the number of retransmits on a per-client basis in
Mikrotik
APs operating in 802.11a/b/g mode (but not Nstreme) by going to
Wireless ->
Registration, double-clicking the client, and going to the Statistics tab.

With regular 802.11a/b/g, the radios transmit and receive only when there is a packet to be sent. One packet is sent in each RF/wireless ethernet/Hw (hardware) frame. So one packet = one Hw (hardware) frame. If there is more than one Hw frame, it's because Mikrotik handed the packet to the wireless card hardware, it sent it, didn't get the Ack, and sent it again. That's how hardware frames become higher than software frames/packets.

Mikrotik doesn't publish the guts of the Nstreme protocol, so I can't speak too specifically about it. I know that Nstreme is capable of putting multiple packets into a single frame. This *might* cause the number of hardware frames to be LESS than software frames, but I haven't tested that and am not sure of it. In my experience, hardware frames is always MORE than software frames. I use polling. I haven't done any testing, but my guess is that the polling mechanism in Nstreme causes there to be constant hardware frames, as the AP is constantly talking to the clients and asking, "do you have data to transmit?" causing there to be hardware frames when there are no software trames being transmitted.

I haven't tried this, but disabling polling and putting framer-policy to none might get software and hardware frame counts to a one-to-one ratio except for retransmits. Changing these settings will cause all clients to disconnect for a second and then immediately reconnect using the new settings. You won't get much of a performance benefit for running Nstreme while configured like this, but on a temporary basis, it would allow you to see retransmit levels for a user. Again, I haven't tried this, so it may not have the desired affect of letting you see retransmit levels, but it's an idea.

Dave

----- Original Message ----- From: "Paul Hendry" <[EMAIL PROTECTED]>
To: "'WISPA General List'" <wireless@wispa.org>
Sent: Saturday, June 03, 2006 3:41 PM
Subject: RE: [WISPA] Mikrotik Virtual AP


I'm using NStreme on both the AP and client devices. Would these figures not
reflect the same thing in an NStreme environment and if not why not?


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Sovereen
Sent: 03 June 2006 15:49
To: wireless@wispa.org
Subject: Re: [WISPA] Mikrotik Virtual AP

Following up to my own post...

Short of removing the RF interference (relocate CPE, cut down a branch, a
tree, etc), about all you can do is increase the gain of the client's
antenna.  As an alternative to looking at the jitter and packet loss at the
IP layer, these numbers will help you quantify whether or not you are
improving the customer's connection (and as a result, the performance of all
customers on the same AP).

If you take TX Frames and divide into TX Hw Frames, subtract 1, and ignore
the negative sign or multiply by -1 (i.e. ((TX Frames / TX Hw Frames) - 1)
* -1), you will get the percentage of retransmits.  This number should be as
low as possible.  High retransmit rates affect the service and performance
of all customers on an AP.

Dave

989-837-3790 x 151
989-837-3780 fax

[EMAIL PROTECTED]
www.mercury.net

129 Ashman St, Midland, MI  48640
----- Original Message ----- From: "David Sovereen" <[EMAIL PROTECTED]>
To: "WISPA General List" <wireless@wispa.org>
Sent: Saturday, June 03, 2006 10:29 AM
Subject: Re: [WISPA] Mikrotik Virtual AP


There isn't much you can do; we're not given controls over settings at
that
low layer.

You can quantify the number of retransmits on a per-client basis in
Mikrotik
APs operating in 802.11a/b/g mode (but not Nstreme) by going to
Wireless ->
Registration, double-clicking the client, and going to the Statistics tab.

Compare TX Frames with TX Hw Frames.  TX Frames is the number of packets
sent from the upper layer (typically IP or PPPoE, but could be other
protocols) to the RF/wireless ethernet layer.  TX Hw Frames is the number
of
packets sent over the air, including re-transmits.  In a perfect
environment, these numbers will be equal, i.e. 10,000 IP packets = 10,000
RF/wireless ethernet frames.  If a 10 packets needed to be retransmitted,
then the example I'm using would show 10,010 TX Hw Frames.

Retransmissions from the client to the AP can only be seen on the client
side.  If the client is running Mikrotik, you will find the information in
the same place looking at the same TX statistics.  Not all equipment
provides this information.

Dave

989-837-3790 x 151
989-837-3780 fax

[EMAIL PROTECTED]
www.mercury.net

129 Ashman St, Midland, MI  48640
----- Original Message ----- From: "Paul Hendry" <[EMAIL PROTECTED]>
To: "'WISPA General List'" <wireless@wispa.org>
Sent: Saturday, June 03, 2006 10:11 AM
Subject: RE: [WISPA] Mikrotik Virtual AP


Thought as much but was hoping it might have been an issue further up the
stack. Anyone know if the number of retransmits can be adjusted or if
there
are any other tweaks to make the impact minimal?

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of David Sovereen
Sent: 03 June 2006 14:46
To: WISPA General List
Subject: Re: [WISPA] Mikrotik Virtual AP

Hi Paul,

It's an RF problem.  802.11a/b/g and Nstreme all have packet
acknowledgement
in the protocol.  Every packet your AP sends needs to be acknowledged by
the
client.  When a packet is not acknowledged, the AP retransmits it.
Because
of poor RF conditions (NLOS), RF/wireless ethernet packets are being lost.
When this happens, the AP retransmits the unacknowledged packets
automatically.

When you see packet loss at the IP layer (i.e. ping timeout), your packet
has been lost and retransmitted at the RF/wireless ethernet layer by the
AP
many times over again.  Retransmissions take up significant air time
because
your AP is waiting until the Ack timeout, typically up to 400usec, for the
Acknowledgement to come back and isn't transmitting anything else during
that time.  It retransmits the packet over and over.  One packet like this
isn't in itself a problem.  But when it happens on a data stream of 20
packets/sec, it is!  Because your AP is trying and waiting and trying and

waiting to get these packets through, other customers are being impacted.

Moving this customer to a Virtual AP will have zero affect.  The same
packet
acknowledgement/transmission problem will occur, and all customers,
regardless of SSID will be affected.

Your best move is to drop this customer, or if you really want to keep the
customer and not impact your other customers, move him to another
radio/antenna.  RF packet loss is costly in terms of overall AP capacity.
Keeping customers who have significant RF packet loss can cut total AP
capacity in half or worse, depending on severity.

Regards,

Dave

989-837-3790 x 151
989-837-3780 fax

[EMAIL PROTECTED]
www.mercury.net

129 Ashman St, Midland, MI  48640
----- Original Message ----- From: "Paul Hendry" <[EMAIL PROTECTED]>
To: "'WISPA General List'" <wireless@wispa.org>
Sent: Saturday, June 03, 2006 9:21 AM
Subject: [WISPA] Mikrotik Virtual AP


Ola,



            I currently have a scenario where a dozen clients are
connected
to a 5.8GHz AP where one is a NLOS link. The link quality is fine for this
client during normal conditions but when it rains it becomes a little
unstable which the customer is fine with as they have no alternative. The
problem that I have is when the weather is poor it can cause a lot of
jitter
to the other clients on the same AP especially when the NLOS link is
trying
to be used. I’m wondering if this is an RF or IP issue. If it’s an issue
at
the IP layer then I wonder if setting up a Mikrotik box as the AP with a
virtual AP for the NLOS link and a virtual AP for the rest would get round
this problem.



            Any thoughts or experiences??



Cheers,



P



Skyline Networks & Consultancy Ltd

Web: HYPERLINK
"http://www.skyline-networks.com"http://www.skyline-networks.com





This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom it is addressed.
If
you have received this email in error please notify the sender.  Whilst
every endeavour is taken to ensure that emails are free from viruses, no
liability can be accepted for any damage arising from using this email.




--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/354 - Release Date: 01/06/2006




--------------------------------------------------------------------------
--
----


> -- > WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006


--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/


--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.1/355 - Release Date: 02/06/2006


--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to