Moving Arev from Novell to NT part 2 (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>category:"AREV Specific"}}

[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== Moving Arev from Novell to NT part 2 (AREV Specific) ====
=== At 08 MAR 1999 07:44:18PM David Craig wrote: ===
 
 
<QUOTE>
As I posted before, we're getting ready to move our Arev application over from our Novell Server to an NT server.  Looking into things deeper I've come up with a couple more questions.  



First is the Network Lan Pack: it appears that this is not network specific but I'm not sure if this is true.  The documentation on the disk (there's no version on the disk or docs) says it supports the following networks: DOS 3.1, LAN Manager, LAN Server, 3Com 3+ 3Open, IBM PC LAN, Netware Lite and LANtastic, GrapeVine LAN OS along with Netware.  I think that one of these old network OS's is the precursor to NT (PC LAN? DOS 3.1?) and that therefore it should be fine but I'm not sure.  Is there a different LAN pack for NT or is this the only one?  



Second is about the registry settings for turning off opportunistic locking on the NT Server.  The answers we've gotten so far about running Arev on NT Server state we should disable opportunistic file locking and that there were three registry settings for this.  



Here's what I've found:

EnableOplocks REG_DWORD	0,1(default is 1)

MinLinkThroughput REG_DWORD 0.. infinite (default is 0)

MaxLinkDelay REG_DWORD 1..100,000 seconds(default is 60)

OplockBreakWait REG_DWORD 10..180 seconds(default is 35)



To disable Oplocks I would set the first to 0, but what about the other settings, are there recommended values for this or is it something we just have to try out and see what works best?  



Again; thanks in advance for any help, the tip about forcedos (thanks Steve) for NT workstation has made Arev run noticably better on my workstation.  



(Current configuration is a mixed environment of NT4.3 and Novell 4.11 running Arev3.12, we're using the current NLM and have the NT Service/NPP for when we migrate over to NT4 sp 3.  Clients are primarily about 23 users with W95 and one each W98 and NT4.3 client)



David Craig

ABC-CLIO
</QUOTE>
----

=== At 09 MAR 1999 01:05AM Don Bakke wrote:  ===

<QUOTE>David,



You should know that the only supported network driver for NT and Win95 clients is the NT Service.



Beyond that if you were to use a driver it would be any of the Byte-range type drivers (i.e. DOS 3.1+).



dbakke@srpcs.com

[url=http://www.srpcs.com]SRP Computer Solutions[/url]

[img]http://www.srpcs.com/srpicon1.gif[/img]

</QUOTE>

----

=== At 09 MAR 1999 03:02PM Warren wrote:  ===

<QUOTE>I thought the NPP "All Networks" driver gets around opportunistic file locking...

</QUOTE>

----

=== At 09 MAR 1999 03:35PM David Craig wrote:  ===

<QUOTE>Author:Warren 

]I thought the NPP "All Networks" driver gets around opportunistic file locking...



If that's true then this is a non-issue as we have the NT Service/NPP, but it was recommended that we disable opportunistic file locking on the server by another poster.  Anyone know for sure?  



David Craig

ABC-CLIO

</QUOTE>

----

=== At 09 MAR 1999 07:04PM Warren wrote:  ===

<QUOTE>To quote the Knowledge Base article "Choosing the Correct Revelation Network Product for your Network":



"If you are running Windows 95 or Windows NT workstations, you are required to use the "All Networks" or the Revelation NLM . The 'All Networks' driver and the Revelation NLM both resolve problems introduced with 'Opportunistic Locking' and 'Write-Behind Caching' implemented in Win95/WinNT"

</QUOTE>

----

=== At 09 MAR 1999 07:53PM David Craig wrote:  ===

<QUOTE>Thanks Warren.  That eliminates one (more) potential problem.

</QUOTE>

----

=== At 09 MAR 1999 08:06PM David Craig wrote:  ===

<QUOTE>Don;



Are you saying that the NT Service replaces the Lan pack as the network driver?  As you can tell, I didn't install Arev initially so I'm not exactly sure what piece goes where and what's required for what.  



Thanks for your patience;



David Craig

ABC-CLIO

</QUOTE>

----

=== At 10 MAR 1999 02:53PM Warren wrote:  ===

<QUOTE>David:



The NT Service: moves most of the Linear Hash Filing System to the NT server. It provides a pseudo client/server model.



Lan Pack: this upgrades the total user license for multiuser Advance Revelation, in increments of 4 or 5



Network Performance Pack: this is set of new network locking drivers, often called 'enhanced byte-range locking drivers' by RTI. Required by the NT service. Note: both the NT service and the NPP drivers must be the same revision (e.g. v1.5).



Hope this help clarify things.

</QUOTE>

----

=== At 11 MAR 1999 10:32AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:  ===

<QUOTE>The two articles below are taken from Microsoft Technical Support documentation.  I think the first one speaks volumes on the subject.



akaplan@sprezzatura.com

[url=http://www.sprezzatura.com]Sprezzatura Group[/url]

[img]http://www.sprezzatura.com/zz.jpg[/img]





[size=5][b]

Delay saving Word 7.0 file to network drive due to ignoring oplock request.

[/b][/size]







Error:--]











Cause:

The delay saving the Microsoft Word 7.0 file to a network drive is caused by the Windows NT client ignoring the oplock (opportunistic lock) break request from the server.











Solution:

Install Service Pack 3 to correct this problem.  Service Pack 3 can be obtained at:

http://www.microsoft.com/kb/softlib/

As a workaround, you can edit the registry to disable the oplock feature on the remote Windows NT computer.











[i][color=Green]NOTE: Do not perform the following procedure if you have applied Service Pack 3.  The following workaround is intended to correct this problem on computers which are not running Service Pack 3, by disabling the oplock (opportunistic lock) feature on the remote Windows NT server.[/color][/i]

[i][color=Red]CAUTION: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them.  Read the following procedure carefully before proceeding.[/color][/i]

[b]1)[/b] [url=http://support.microsoft.com/support/ntserver/serviceware/nts40/371HHLC8.ASP]Run the program[/url] REGEDT32.

[b]2)[/b] [url=http://support.microsoft.com/support/ntserver/serviceware/nts40/371IUFX1.ASP]Navigate to the following key[/url]:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

[b]3)[/b] [url=http://support.microsoft.com/support/ntserver/serviceware/nts40/371IX6HI.ASP]Add the value entry[/url] 'EnableOplocks' of [url=http://support.microsoft.com/support/ntserver/serviceware/nts40/371IX6BP.ASP]data type[/url] REG_DWORD, and set the value to 0.

[i][color=Green]NOTE 1: If the parameter 'EnableOplocks' already exists, set the value to 0.[/color][/i]

[i][color=Green]NOTE 2: The range of values for 'EnableOplocks' is 0 (disabled) to 1 (enabled).[/color][/i]

[b]4)[/b] Exit the Registry Editor and restart the computer to enable the new settings.







[size=2]



PC Ext: Explanation of Opportunistic Locking on Windows NT





 

 

The information in this article applies to:



[list][*]Microsoft Mail for PC Networks versions 3.0, 3.2, and 3.2a, 3.5

[*]Microsoft Windows NT Workstation version 3.5, 3.51, and 4.0

[*]Microsoft Windows NT Server version 3.5, 3.51, and 4.0

[/list] 







SUMMARY

 





With Exclusive Oplock, if a file is opened in a non-exclusive (deny none)

mode, the redirector requests an opportunistic lock of the entire file. As

long as no other process has the file open, the server will grant this

oplock, giving the redirector exclusive access to the specified file. This

will allow the redirector to perform read-ahead, write-behind, and lock

caching, as long as no other process tries to open the file.





When a second process attempts to open the file, the original owner will

be asked to Break Oplock or Break to Level II Oplock. At that point, the

redirector must invalidate cached data, flush writes and locks, and

release the oplock, or close the file.





Opportunistic Locking level II, provides a method for granting read access

to a file by more than one workstation, and these workstations can cache

read data locally (read-ahead). As long as no station writes to the file,

multiple stations can have the file open with level II oplock.







MORE INFORMATION

 





An illustration of how level II oplocks work:



[list=1]

[*]Station 1 opens the file, requesting oplock.





[*]Since no other station has the file open, the server grants

   station 1 exclusive oplock.





[*]Station 2 opens the file, requesting oplock.





[*]Since station 1 has not yet written to the file, the server asks

   station 1 to Break to Level II Oplock.





[*]Station 1 complies by flushing locally buffered lock information to

   the server.





[*]Station 1 informs the server that it has Broken to Level II Oplock

   (alternatively, station 1 could have closed the file).





[*]The server responds to station 2's open request, granting it level II

   oplock. Other stations can likewise open the file and obtain level II

   oplock.





[*]Station 2 (or any station that has the file open) sends a write request

   SMB. The server returns the write response.





[*]The server asks all stations that have the file open to Break to None,

   meaning no station holds any oplock on the file. Because the

   workstations can have no cached writes or locks at this point, they

   need not respond to the break-to-none advisory; all they need do is

   invalidate locally cashed read-ahead data.





[/list]The following registry entries are used to enable or disable oplocks for

Windows NT Workstation or Server. These registry keys may not exist by

default. To access the registry run REGEDT32.EXE from the File menu,

choose Run in Program Manager or File Manager.





WARNING: Using Registry Editor incorrectly can cause serious, system-wide

problems that may require you to reinstall Windows NT to correct them.

Microsoft cannot guarantee that any problems resulting from the use of

Registry Editor can be solved. Use this tool at your own risk.







Workstation Service Entries

 





\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet


<code>
   \Services\LanmanWorkstation\Parameters

UseOpportunisticLocking   REG_DWORD   0 or 1

</code>
[/list]Default: 1 (true)





Indicates whether the redirector should use opportunistic-locking (oplock)

performance enhancement. This parameter should be disabled only to isolate

problems.







Server Service Entries

 





\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet


<code>
   \Services\LanmanServer\Parameters

EnableOplocks   REG_DWORD   0 or 1

</code>
Default: 1 (true)





Specifies whether the server allows clients to use oplocks on files.

Oplocks are a significant performance enhancement, but have the potential

to cause lost cached data on some networks, particularly wide-area

networks.






<code>
MinLinkThroughput   REG_DWORD   0 to infinite bytes per second

</code>
Default: 0





Specifies the minimum link throughput allowed by the server before it

disables raw and opportunistic locks for this connection.






<code>
MaxLinkDelay   REG_DWORD   0 to 100,000 seconds

</code>
Default: 60





Specifies the maximum time allowed for a link delay. If delays exceed this

number, the server disables raw I/O and opportunistic locking for this

connection.






<code>
OplockBreakWait   REG_DWORD   10 to 180 seconds

</code>
Default: 35





Specifies the time that the server waits for a client to respond to an

oplock break request. Smaller values can allow detection of crashed

clients more quickly but can potentially cause loss of cached data.





[/size]

</QUOTE>

----

=== At 11 MAR 1999 10:46AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:  ===

<QUOTE>I know it says that, but I don't trust those features at all.  In a heavy transaction system like ARev/OI/RevG (databases, basically) I don't want a workstation holding onto anything.  The server should be managing the cache, that's part of what it's there for and why these things get loaded with 9 hundred billion megs of memory, so they can cache boat loads of info.  



With LH it just makes it worse, because the server has no clue about the 20 records I'm holding on to, which makes resizing all that much more fun.



The NLM and NT Service should handle it better, seeing as how they'll handle the record when it gets back to them, assuming the cache doesn't try and bypass it somehow.  I remember hearing the NPP has code that ignores the setting, which is how it eliminates the problem.



Still, no matter how much Revelation might inisist the new networking products solve the problems, I don't trust MS to do the job properly and turn them off anyway.



95/98/NT spend way too much time deciding what you meant to do instead of doing what you asked it to do.





akaplan@sprezzatura.com

[url=http://www.sprezzatura.com]Sprezzatura Group[/url]

[img]http://www.sprezzatura.com/zz.jpg[/img]

</QUOTE>

----

=== At 11 MAR 1999 02:05PM Victor Engel wrote:  ===

<QUOTE>]95/98/NT spend way too much time deciding what you meant to do instead of doing what you asked it to do.



Truer words have never been spoken!

</QUOTE>

----

=== At 11 MAR 1999 03:22PM David Craig wrote:  ===

<QUOTE>Thanks Aaron,



This explains a couple of things, first why I couldn't figure it out through the documentation and second why I'm getting somewhat conflicting answers.  Our application is about 1.1 gigs of intricately related text so I wish to do whatever is safest first, and performs well second.  



So if I set EnableOplocks to 0 and accept the defaults for 

MinLinkThroughput (0), MaxLinkDelay (60), and OplockBreakWait (35), should that do it or should I change the other settings as well?



Thanks again;



David Craig

ABC-CLIO

</QUOTE>

----

=== At 11 MAR 1999 03:27PM David Craig wrote:  ===

<QUOTE>It does indeed help.  Sometimes it feels like I'm assembling a jigsaw puzzle without a picture on it instead of installing software.  



On the other hand, I'd rather have to figure it out myself than have the software figure it out for me and get it wrong.  



Thanks again for your time and patience;



David Craig

ABC-CLIO

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=8EBCD5F04F64F2828525672F00040E80|View this thread on the  forum...]]