Is there a way to limit packets per second without dropping it i want pps above 40 to be delayed to next second i can limit with iptables with these commands but it will be dropped
Iptables -A POSTROUTING - t mangle -d 192.168.1.100/32 -m limit - - limit 40/s - j ACCEPT
iptables - j DROP -A POSTROUTING -d 192.168.1.100/32 -t mangle
Not without increasing latency, which will likely lower FPS and PPS.
SQM may be a better choice, but I don't think it will work with such a rate. The difference is that SQM will not try to drop at first, it will send the device a ECN (explicit congestion notification) telling it to calm down.
Assuming the flow in question actually uses ECN in the first place ;), for non ECN flows (or better packets without the ECT(0) or ECT(1) ECN codepoint) sqm will simply drop the packet.
ECN in the wireless link or Ethernet port does not happen to mangle ECN/DSCP because there is no ISP inside your network.
All Apple devices support ECN, and all Android/Linux devices since Linux 3.11 use ECN by default.
I am not 100% sure I understand your point? ECN marking (or better setting the CE-codepoint in an IP packets 2 bit ECN field that arlready carried either the ECT(0) or the ECT(1) codepoint) is something an rfc3169/ECN compliant AQM (active queue management) system might do, independent of its location. For example sqm-scripts allows the user to set up an ECN capable AQM in her home (but non-ECN enabled flows will still just get drops).
Yes, it is getting more use lately, but that still dos not change the fact that ECN signaling is restricted to flows that signal ECN-compatibility by setting either ECT(0) or ECT(1). 
You can use a qdisc to limit bandwidth (or the "packets per second") to a given rate without dropping packages in a local network because it uses ECN, which it's designed to avoid packet drop.
It's that clear enough to you?
A simple firewall rules to override the ECN bits is enough for it to work in a forwarding/NAT LAN.
Well, you only can do this if you flows actually honor the ECN signal otherwise you need to drop (and both cake and fq_codel will do at one point. This is required as with ECN a flow basically promises a specific back-off response to an ECN signal, but might not actually deliver that, either because the flow is evil and just set ECT(0) to gain a bandwidth advantage over non-ECN flows, or the flow is already at the one packet congestion window (and hence will not scale back).
So, I agree that with properly selected and configured well-behaving endpoints it can be possibly to limit bandwidth without drops, but that is IMHO the exception, not the rule.
I do believe that for the OP "use ECN" is not really a viable option (many games use UDP based transport flows for state exchange, and in UDP there is no reliable ECN-support each individual application needs to implement ECN support individually, and as far as I know, not many have done so).
Whatever... I won't say anything anymore.
Think you are smart enough? Give the OP a real solution instead of arguing.
Good day, sir.
Good point.
Well, not really, you can put a large queue in front of your egress traffic shaper and avoid using any AQM, and simply operate that as a FIFO, but this will, if the internal traffic generation rate exceeds the shaper setting:
a) keep increasing the queue length so that each added packet will have to wait longer before it can be send
b) at one point the queue will be full and dropping will need to start.
Active queue management (AQM, e.g. sqm) is typically used in similar situations, but this still does not guarantee to never drop packets; in fact as an extension of the last few postings, ECN is a method an AQM can use that can help to reduce the likelihood of having to drop packets (but will not avoid all drops). The idea behind AQMs is to signal to flows when/if they needs to slow down and offer enough queueing space to buffer that flows packets until the sending rate is adjusted.
I guess my bigger question is what is the relevance of the 40 PPS (which is hard/impossible to configure in sqm, which deals in bandwidth not packet counts).